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ABSTRACT 



A plurality of computer nodes communicate using seem- 
ingly random Internet Protocol source and destination 
addresses. Data packets matching criteria defined by a 
moving window of valid addresses are accepted for further 
processing, while those that do not meet the criteria are 
quickly rejected. Improvements to the basic design include 

(1) a load balancer that distributes packets across different 
transmission paths according to transmission path quality; 

(2) a DNS proxy server that transparently creates a virtual 
private network in response to a domain name inquiry; (3) 
a large-to-small link bandwidth management feature that 
prevents denial-of-service attacks at system chokepoints; (4) 
a traffic Umiter that regulates incoming packets by limiting 
the rate at which a transmitter can be synchronized with a 
receiver; and (5) a signaling synchronizer that allows a large 
number of nodes to communicate with a central node by 
partitioning the communication function between two sepa- 
rate entities. 

17 Claims, 35 Drawing Sheets 
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AGILE NETWORK PROTOCOL FOR 
SECURE COMMUNICATIONS WITH 
ASSURED SYSTEM AVAnABILITY 

CROSS-REFERENCE TO RELATED 
APPLICAnON 

This application claims priority from and is a 
continuation-in-part of previously filed U.S. application Ser. 
No. 09/429,643, filed on Oct. 29, 1999. The subject matter 
of that application, which is bodily incorporated herein, 
derives from provisional U.S. application No. 60/106,261 
(filed Oct. 30, 1998) and No. 60/137,704 (filed Jun. 7, 1999). 

BACKGROUND OF THE INVENTION 

A tremendous variety of methods have been proposed and 
implemented to provide security and anonymity for com- 
munications over the Internet. The variety stems, in part, 
from the different needs of different Internet users. A basic 
heuristic framework to aid in discussing these different 
security techniques is illustrated in FIG. 1. Two terminals, an 
originating terminal 100 and a destination terminal 110 are 
in communication over the Internet. It is desired for the 
communications to be secure, that is, immune to eavesdrop- 
ping. For example, terminal 100 may transmit secret infor- 
mation to terminal 110 over the Internet 107. Also, it may be 
desired to prevent an eavesdropper from discovering that 
terminal 100 is in communication with terminal 110. For 
example, if terminal 100 is a user and terminal 110 hosts a 
web site, terminal lOO's user may not want anyone in the 
intervening networks to know what web sites he is "visit- 
ing." Anonymity would thus be an issue, for example, for 
companies that want to keep their market research interests 
private and thiis would prefer to prevent outsiders from 
knowing which web-sites or other Internet resources they 
are "visiting." These two security issues may be called data 
security and anonymity, respectively. 

Data security is usually tackled using some form of data 
encryption. An encryption key 48 is known at both the 
originating and terminating terminals 100 and 110. The keys 
may be private and public at the originating and destination 
terminals 100 and 110, respectively or they may be sym- 
metrical keys (the same key is used by both parties to 
encrypt and decrypt). Many encryption methods are known 
and usable in this context. 

To hide traffic from a local administrator or ISP, a user can 
employ a local proxy server in communicating over an 
encrypted channel with an outside proxy such that the local 
administrator or ISP only sees the encrypted traflSc. Proxy 
servers prevent destination servers from determining the 
identities of the originating chents. This system employs an 
intermediate server interposed between client and destina- 
tion server. The destination server sees only the Internet 
Protocol (IP) address of the proxy server and not the 
originating cUent. The target server only sees the address of 
the outside proxy. This scheme relies on a trusted outside 
proxy server. Also, proxy schemes are vulnerable to traffic 
analysis methods of determining identities of transmitters 
and receivers. Another important limitation of proxy servers 
is that the server knows the identities of both calling and 
called parties. In many instances, an originating terminal, 
such as terminal A, would prefer to keep its identity con- 
cealed from the proxy, for example, if the proxy server is 
provided by an Internet service provider (ISP). 

To defeat trafSc analysis, a scheme called Chaum's mixes 
employs a proxy server that transmits and receives fixed 
length messages, including dummy messages. Multiple 
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originating terminals are connected through a mix (a server) 
to multiple target servers. It is difiBcult to tell which of the 
originating terminals are communicating to which of the 
connected target servers, and the dummy messages confuse 

5 eavesdroppers' efforts to detect communicating pairs by 
analyzing traflBc. A drawback is that there is a risk that the 
mix server could be compromised. One way to deal with this 
risk is to spread the trust among multiple mixes. If one mix 
is compromised, the identities of the originating and target 

10 terminals may remain concealed. This strategy requires a 
number of alternative mixes so that the intermediate servers 
interposed between the originating and target terminals are 
not determinable except by compromising more than one 
mix. The strategy wraps the message with multiple layers of 

15 encrypted addresses. The first mix in a sequence can decrypt 
only the outer layer of the message to reveal the next 
destination mix in sequence. The second mix can decrypt the 
message to reveal the next mix and so on. The target server 
receives the message and, optionally, a multi-layer 

20 encrypted payload containing return information to send 
data back in the same fashion. The only way to defeat such 
a mix scheme is to collude among mixes. If the packets are 
all fixed-length and intermixed with dummy packets, there 
is no way to do any kind of traffic analysis. 

25 Still another anonymity technique, called * crowds,' pro- 
tects the identity of the originating terminal from the inter- 
mediate proxies by providing that originating terminals 
belong to groups of proxies called crowds. The crowd 
proxies are interposed between originating and target termi- 

30 nals. Each proxy through which the message is sent is 
randomly chosen by an upstream proxy. Each intermediate 
proxy can send the message either to another randomly 
chosen proxy in the "crowd" or to the destination. Thus, 
even crowd members cannot determine if a preceding proxy 

35 is the originator of the message or if it was simply passed 
from another proxy. 

ZKS (Zero-Knowledge Systems) Anonymous IP Protocol 
allows users to select up to any of five different pseudonyms, 
while desktop software encrypts outgoing traffic and wraps 
it in User Datagram Protocol (UDP) packets. The first server 
in a 2+-hop system gets the UDP packets, strips off one layer 
of encryption to add another, then sends the traffic to the next 
server, which strips off yet another layer of encryption and 
adds a new one. The user is permitted to control the number 
of hops. At the final server, traffic is decrypted with an 
untraceable IP address. The technique is called onion- 
routing. This method can be defeated using traffic analysis. 
For a simple example, bursts of packets from a user during 
low-duty periods can reveal the identities of sender and 
receiver. 

Firewalls attempt to protect LANs from unauthorized 
access and hostile exploitation or damage to computers 
connected to the LAN. Firewalls provide a server through 
which all access to the LAN must pass. Firewalls are 
centralized systems that require administrative overhead to 
maintain. They can be compromised by virtual-machine 
applications ("applets"). They instill a false sense of security 
that leads to security breaches for example by users sending 
sensitive information to servers outside the firewall or 
encouraging use of modems to sidestep the firewall security. 
Firewalls are not useful for distributed systems such as 
business travelers, extranets, small teams, etc. 

SUMMARY OF THE INVENTION 

65 

A secure mechanism for communicating over the internet, 
including a protocol referred to as the TUnneled Agile 
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Routing Protocol (TARP), uses a unique two-layer encryp- 
tion format and special TARP routers. TARP routers are 
similar in function to regular IP routers. Each TARP router 
has one or more IP addresses and uses normal IP protocol to 
send IP packet messages ("packets" or "datagrams"). The IP 5 
packets exchanged between TARP terminals via TARP rout- 
ers are actually encrypted packets whose true destination 
address is concealed except to TARP. routers and servers. 
The normal or "clear" or "outside" IP header attached to 
TARP IP parVfttR contains only the address of a next hop 
router or destination seryer. mat is, instead ot inaicatmg a 
final destination in the destination field of the IP header, the 
TARP packet's IP header always points to a next-hop in a 
series of TARP router hops, or to the final destination. This 
means there is no overt indication from an intercepted TARP 
packet of the true destiiiation of the TARP packet since the 
destination could always be next-hop TARP router as well as 
the final destination. 

Each TARP packet's true destination is concealed behind 
a layer of encryption generated using a link key. The link key 
is the encrjTption key used for encrypted communication 
between the hops intervening between an originating TARP 
terminal and a destination TARP ^ternainal. Each TARP 
router can remove the outer layer of encryption to reveal the 
destination router for each TARP packet. To identify the link 
key needed to decrypt the outer layer of encryption of a 
TARP packet, a receiving TARP or routing terminal may 
identify the transmitting terminal by the sender/receiver IP 
numbers in the cleartext IP header. 

Once the outer layer of encryption is removed, the TARP 3Q 
router determines the final destination. Each TARP packet 
140 undergoes a minimum number of hops to help foil traffic 
analysis. The hops may be chosen at random or by a fixed 
value. As a result, each TARP packet may make random trips 
among a number of geographically disparate routers before 35 
reaching its destination. Each trip is highly likely to be 
different for each packet composing a given message 
because each, trip is independently randomly determined. 
/ This feature is called agile routing. The fact that different 
I packets take different routes provides distinct advantages by 
I making it difficult for an interloper to obtain all the packets 
1 forming an ei\tire multi-packet message. The associated 
V advantages have to do with the inner layer of encryption 
discussed below. Agile routing is combined with another 
feature that furthers this purpose; a feature that ensures that 45 
any message is broken into muUiple packets. 

The IP address of a TARP router can be changed, a feature 
called IP agihty. Each TARP router, independently or under 
direction from another TARP terminal or router, can change 
^ its IP address. A separate, unchangeable identifier or address 50 
is also defined; This address, called the TARP address, is 
/ known only to TARP routers and terminals and may be 
( correlated at any time by a TARP router or a TARP terminal 
\ using a Lookup Table (LVT). When a TARP router or 
terminal cnanges its rP'SdSress; it updates the other TARP 55 
routers and terminals which in turn update their respective 
LUTs. 

The message payload is hidden behind an inner layer of 
encryption in the TARP packet that can only be unlocked 
using a session key. The session key is not available to any 60 
of the intervening TARP routers. The session key is used to 
decrypt the payloads of the TARP packets permitting the 
data stream to be reconstructed. 

Communication may be made private using link and 
session keys, which in turn may be shared and used accord- 65 
ing to any desired method. For example, pubUc/private keys 
or symmetric keys may be used. 



To transmit a data stream, a TARP originating terminal 
constructs a series of TARP packets from a series of IP 
packets generated by a network (IP) layer process. (Note that 
the terms "network layer," "data Unk layer," "apphcation 
layer," etc. used in this specification correspond to the Open 
Systems Intercomection (OSI) network terminology.) The 
payloads of these packets are assembled into a block and 
chain-block encrypted using the session key. This assumes, 
of course, that all the IP packets are destined for the same 
TARP terminal. The block is then interleaved and the 
interleaved encrypted block is broken into a series of 
payloads, one for each TARP packet to be generated. Special 
TARP headers IPT are then added to each payload using the 
IP t^eaders from the data stream packets. T lie TARP headers 
can' be identical to normal IP headers or customized in some 
way. They should contain a formula or data for deinterleav- 
ing the data at the destination TARP terminal, a time-to-live 
(TTL) parameter to indicate the number of hops still to be 
executed, a data type identifier which indicates whether the 
payload contains, for example, TCP or UDP data, the 
sender's TARP address, the destination TARP address, and 
an indicator as to whether the packet contains real or decoy 
data or a formula for filtering out decoy data if decoy data 
is spread in some way through the TARP payload data. 

Note that although chain-block encryption is discussed 
here with reference to the session key, any encryption 
method may be used. Preferably, as in chain block 
encryption, a method should be used that makes unautho- 
rized decryption difficult without an entire result of the 
encryption process. Thus, by separating the encrypted block 
among multiple packets and making it difiScult for an 
interloper to obtain access to all of such packets, the contents 
of the communications are provided an extra layer of 
security. 

Decoy or dummy data can be added to a stream to help 
foil traffic analysis by reducing the peak-to-average network 
load. It may be desirable to provide the TARP process with 
an ability to respond to the time of day or other criteria to 
generate more decoy data during low trafiSc periods so that 
communication bursts at one point in the Internet cannot be 
tied to communication bursts at another point to reveal the 
communicating endpoints. 

Dummy data also helps to break the data into a larger 
number of inconspicuously-sized packets permitting the 
interleave wmdow size to be increased while maintaining a~ 
reasonable size for each packet. ( i ne packet size can be a " 
si n^e standard size or selectedfrom a fixed range of sizes.) J 
"^e pnmary rcason lor aesmng tor each message to be~^ 
broken into multiple packets is apparent if a chain block 
encryption scheme is used to form the first encryption layer 
prior to interleaving. A single block encryption may be 
appUed to portion, or entirety, of a message,~and that portion 
or entirety then interleaved into a ''number of separate 
packets. Considering the agile IP routing of the packets, and 
the attendant difficulty of reconstructing an entire sequence 
of p^kets to form a single block-encrypted message 
element, decoy packets can significantly increase the diffi- 
culty of reconstructing an entire data stream. 

The above scheme may be implemenTed entirely by 
processes operating between the data link layer and the 
network layer of each server oF terminal participating in the 
TARP system. Because the encryption system described 
above is insertable between the data link and network layers, 
the processes involved in supporting the encrypted commu- 
nication may be completely transparent to processes at the IP 
(networic) layer and above. The TARP processes may also be 
completely transparent to the data link layer processes as 
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well. Thiis, no opera tioas at or above the Network layer, or transmission path quality; (2) a DNS proxy server that 

at or below the data link layer, are affected by the insertion transparently creates a virtual private network in response to 

of the TARP stack. This provides additional security to all a domain name inquiry; (3) a large-to-small link bandwidth 

processes at or above the network layer, since the difficulty management feature that prevents denial-of-service attacks 
of unauthorized penetration of the network layer (by, for 5 at system chokepoints; (4) a traffic Umiter that regulates 

example, a hacker) is increased substantially. Even newly incoming packets by hmiting the rate at which a transmitter 

developed servers running at the session layer leave all can be synchronized with a receiver; and (5) a signaUng 

processes below the session layer vulnerable to attack. Note synchronizer that allows a large number of nodes to com- 

that in this architecture, security is distributed. That is, municale with a central node by partitioning the communi- 
notebook computers used by executives on the road, for lO cation function between two separate entities 
example, can communicate over the Internet without any 

compromise in security. BRIEF DESCRIPTION OF THE DRAWINGS 

IP address cha nges made by TARP terminals and routers FIG. 1 is an illustration of secure communications over 

c an be done at rcgul^uint^als. at random intervals, or upo n the Internet according to a prior art embodiment. 
d Petection of "a U aclis^ of IP addresses tiinders 15 FIG. 2 is an illustration of secure communications over 

trafi&c analysis that might reveal which computers are the Internet according to a an embodiment of the invention, 

communicating, and also provides a degree of immunity piQ. 3a is an illustration of a process of forming a \ 

from attack. The level of immunity from attack is roughly tunneled IP packet according to an embodiment of the J 

proportional to the rate at which the IP address of the host invention. 

is changing. Pjq ^ illustration of a process of forming a i 

As mentioned, IP addresses may be changed in response tunneled IP packet according to another embodiment of the j 

to attacks. An attack may be revealed, for example, by a invention. 

regular ^fiOSS ^essages indicating that a router is being 4 ^„ illustration of an OSI layer location of 

probed in some way. Upon_detection of an attack, the TARP processes that may be used to implement the invention, 

layer process may respond to this event by changmg its IP c • « u n * *• t 

1 jj*.- * u fu 7 • FIG. 5 IS a flow chart lUustratmg a process for routmg a 

address. In addition, it may create a subprocess that mam- ^ , , , , , . j- . r • 

, . " , • • 1 in jj J ^- • * tunneled packet according to an embodmaent of the mven- 

tains the onginal IP address and continues interactmg with ^.^^ ^ 

the attacker in some manner. ^ . « . . r r 

^ , , , , . rr.^ T^T^ • 1 FIG. 6 is a now chart illustrating a process for forming a 

Decoy packets may be generated by each TARP terminal . , j . . j. . u j- * ^ *i. • 

L • J . "v^-u 1 — -rt 1 30 tunneled packet according to an embodiment of the mven- 

on^ome basis deterrmnea by an algorithm. For example, the ^.^^ 

algorithm may be a random one which.calls for the genera- * ^ „ . ^ . -.t 

tion of a packet oTiTindom basis when the terminal is idle. ^IG. 7 is a flow chart Ulustratmg a process for receiving 

Altemariv^ely,^the algorithm may be responsive to time of ^ ^""^^^^ P^^*^^^ accordmg to an embodiment of the 

day or detection of low traffic to generate more decoy invention. 

packets during low traffic times.^ Note that packets are FIG. 8 shows how a secure session is estabhshed and 

preferably generated in g roups, r ather than one by one, the synchronized between a client and a TARP router. 

^groups being sized to simuIafelSal messa^ yes. In addition- so' FIG. 9 shows an IP address hopping scheme between a 

that decoy packets may be inserted in normal TARP message client computer and TARP router using transmit and receive 

streams, the background loop may have a latch that makes tables in each computer. 

it more likely to insert decoy packets when a message stream FIG. 10 shows physical link redundancy among three 

is being received. Alternatively, if a large number of decoy Internet Service Providers (ISPs) and a client computer, 

packets is received along with regular TARP packets, the piQ. 11 shows how multiple IP packets can be embedded 

algorithm may increase the rate of dropping of decoy into a single "frame" such as an Ethernet frame, and further 

packets rather than forwarding them. The result of dropping shows the use of a discriminator field to camouflage true 

and generating decoy packets in this way is to make the packet recipients. 

apparent incoming message size different from the apparent p^j ^2 A shows a system that employs hopped hardware 

outgoing message size to help foil traffic analysis. addresses, hopped IP addresses, and hopped discriminator 

Ip various other embodiments of the invention, a scalable fields, 

version of the system may be constructed in which a 50 piQ shows several different approaches for hopping 

plurality of IP addresses are preassigned to each pair of hardware addresses, IP addresses, and discriminator fields in 

communicating nodes in the network. Each pair of nodes combination 

'^r' ^° :''°PPi°f "between IP p,Q ^3' ^^^^^ ^ technique for automatically 

addresses (both sendmg and receivme), such that an eaves- . ui- u- u • u * j j - 

---^i-^ f . f^' , .1 re-establishing synchronization between sender and receiver 
dropper sees apparently continuously random IP addre^ 5s through the use of a partially public sync value, 

pairs (source and destination) for packets transmitted - ^ • , / • » . 

between the pair. Overlapping or "reusable" IP addresses ^^P" ^ checkpomt scheme for regaimng 

may be allocated to different users o5 the same subnet, since synchronization between a sender and recipient, 

each node merely verifies that a particular packet includes a F^^. 15 shows further details of the checkpoint scheme of 
valid source/destination pair from the agreed-upon algo- 

rithm. , Source/destination pairs are preferably not reused FIG. 16 shows how two addresses can be decomposed 

between any two nodes during any given end-to-end session, into a plurality of segments for comparison with presence 

though limited IP block sizes or lengthy sessions might vectors. 

require it. . FIG. 17 shows a storage array for a receiver's active 

Further improvements described in this continuation-in- 65 addresses, 

part application include: (1) a load balancer that distributes FIG. 18 shows the receiver's storage array after receiving 

packets across different transmission paths according to a sync request. 
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FIG. 19 shows the receiver's storage array after new of a TARP packet. To identify the link key needed to decrypt 

addresses have been generated. the outer layer of encryption of a TARP packet, a receiving 

FIG. 20 shows a system employing distributed transmis- '^^^ routing terminal may identify the transmitting 

sion naths terminal (which may indicate the link key used) by the 
^' , n.. , - . . 5 sender field of the clear IP header. Alternatively, this identity 

FIG. 21 shows a plurahty of hnk transmission tables that ^^^y hidden behind another layer of encryption in avaU- 

can be used to route packets in the system of FIG. 20. ^^le bits in the clear IP header. Each TARP router, upon 

FIG. 22 A shows a flowchart for adjusting weight value receiving a TARP message, determines if the message is a 

distributions associated with a plurality of transmission TARP message by using authentication data in the TARP 

links, packet. Th is could be recorded in available Jbvtes ig the 

FIG. 22B shows a flowchart for setting a weight value to TARP pSc Ket's iP heade r Alternatively, TARP packets could 

zero if a transmitter turns off. be aumenticated by attempting to decrypt using the link key 

FIG. 23 shows a system employing distributed transmis- determining if the results are as expected. The 

sion paths with adjusted weight value distributions for each former may have computational advantages because it does 

p^^jj. 15 involve a decryption process. 

no. 24 shows an example using the system of FIG. 23. ^ On«= '^e outer layer of decryption is completed by a 

.7,. TARP router 122-127, the TARP router determines the final 

FIG. 25 shows a conventional domam-name look-up destination. The system is preferably designed to cause each 

service. TARP packet 140 to undergo a minimum number of hops to 

FIG. 26 shows a system employing a DNS proxy server help foil traffic analysis. ITie time to live counter in the IP 

with transparent VPN creation. header of the TARP message may be used to indicate a 

FIG. 27 shows steps that can be carried out to implement number of TARP router hops yet to be completed. Each 

transparent VPN creation based on a DNS look-up function. TARP router then would decrement the counter and deter- 

FIG. 28 shows a system including a link guard function mine from that whether it should forward the TARP packet 

that prevents packet overloading on a low-bandwidth link 25 140 to another TARP router 122-127 or to the destination 

LOW BW. TARP terminal 110. If the time to live counter is zero or ^ 

FIG. 29 shows one embodimem of a system employing l^'Z f ^'"?Pi^ ^.^^"^ (j/^^ J 

the principles of FIG. 28. J^P router receiving the TARP packet 140 may fops^d 

, , , . . th e TARP packet 140 to the destinat ion TARP termmal 110. L 

nC 30 shows a system that regulates packet transmission if the time to Uve counter is above zero after decremenfrnT . m'xhM 

rates by throttling the rate at which synchronizations are ^^^^ ^ ^^^^^^ ^^^^-^ ^ f^CS^"^ 

performed. ^Ar.T^ c j .l. ^a^tx i... ^/T.. . * . li- 



TARP packet 140 may forward the TARP packet 140 to a . j^aMii f^^) 

TARP rniiter 122-127 that the. rnrrent TARP terminfll tT^*"^^ 



DETAILED DESCRIPTION OF THE 
INVENTION 



no. 31 shows a signaling server 3101 and a transport TARP router 122-127 that the current TARP terminal ' 

server 3102 used to establish a VPN with a client computer. chooses at random. As a result, each TARP packet 140 is 

FIG. 32 shows message flows relating to synchronization 35 routed through some minimum number of hops of TARP 

protocols of FIG. 31. routers 122-127 which are chosen at random. 

Thus, each TARP packet, irrespective of the traditional 
factors determining traffic in the Internet, makes random 
trips among a number of geographically disparate routers 

Referring to FIG. 2, a secure mechanism for communi- 40 before reaching its destination and each trip is highly likely 

eating over the internet employs a number of special routers to be different for each packet composing a given message 

or servers, called TARP routers 122-127 that are similar to because each trip is independently randomly determined as 

regular IP routers 128-132 in that each has one or more IP described above. This feature is called agile routing. For 

addresses and uses normal IP protocol to send normal- reasons that will become clear shortly, the fact that different 

looking IP packet messages, called TARP packets 140. 45 packets take different routes provides distinct advantages by 

TARP packets 140 are identical to normal IP packet mes- making it difficult for an interloper to obtain all the packets 

sages that are routed by regular IP routers 128-132 because forming an entire multi-packet m'essage. Agile routing is 

each TARP packet 140 contains a destination address as in combined with another feature that furthers this purpose, a 

a normal IP packet. However, instead of indicating a final feanire that ensures that any message is broken into multiple 

destination in the destination field of the IP header, the TARP 50 packets. 

packet's 140 J£Ji£ fldr .i: always points tn a n e xT-hnp in ,a A TARP router receives a TARP packet when an IP 

seriesofT^RP. router hops, or the final destination, TARP address used by the TARP router coincides with the IP 

terminal 110. Because the header of the TARP packet address in the TARP packet's IP header IP^^. The IP address 

contains only the next-hop destination, there is no overt of a TARP router, however, may not remain constant. To 

indication from an intercepted TARP packet of the true 55 avoid and manage attacks, each TARP router, independently 

destination of the TARP packet 140 since the destination or under direction from another TARP terminal or router, 

could always be the next-hop TARP router as well as the may change its IP address. A separate, unchangeable iden- 

final destination, TARP terminal 110. tifier or address is also defined. This address, called the 

Each TARP packet's true destination is concealed behind TARP address, is known only to TARP routers and terminals 

an outer layer of encryption generated using a link key 146 . 60 and may be correlated at any time by a TARP router or a 

The link key 146 is the encryption key used for encrypted TARP terminal using a Lookup Table (LUT). When a TARP 

/^ommimication between the end points (TARP terminals or router or terminal changes its IP address, it updates the other 
TARP routers U)f a sinele link^inJhe chain of hops connect-^ TARP routers and terminals which in_turn update their 

JngJhe, originating TARP terminal 100 and the destination respective LUTs. In reality, whenever a TARP router looks 

T ARP terminal ll .q, Each TARP router 122-127, using the 65 up the address of a destination in the encrypted header, it 

^ link key 146 it uses to communicate with the previous hop must convert a TARP address to a real IP address using its 

in a cliaia, can use the link key to reveal the true destination LUT, 
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While every TARP router receiv inp a TA RP packet ha s 
the ability to determine the packet's final destination, tne 
message payload is embedded behind an inner layer of 
encryption in the TARP packet that can only be unlocked 
using a session key. The session key is not available to any 
of the TARP routers 122-127 intervening between the 
originating 100 and destination 110 TARP terminals. The 
session key is used to decrypt the payloads of the TARP 
packets 140 permitting an entire message to be recon- 
structed. 

In one embodiment, communication may be made private 
using link and session keys, which in turn may be shared and 
used according any desired method. For example, a public 
key or symmetric keys may be communicated between link 
or session endpoints using a public key method. Any of a 
variety of other mechanisms for securing data to ensure that 
only authorized computers can have access to the private 
information in the TARP packets 140 may be used as 
d esired . 

Referring to FIG. 3fl, to construct a series of TARP 



10 



15 



packets, a data stream 300 of IP packets 207«, 2076, 207c, 
etc., such series of packets being formed by a network (IP) 
layer process, is broken int q a series oismall s ized segm ents.. 
In the present example^ equal-sizea segments 1-v are 
defined and used to construct a set of interleaved data 
packets A, B, and C. Here it is assumed that the number of 
interleaved packets A, B, and C formed is three and that the 
number of IP packets 207fl-207c used to form the three 
interleaved packets A, B, and C is exactly three. Of course, 
the number of IP packets spread over a group of interleaved 
packets may be any convenient number as may be the 
number of interleaved packets over which the incoming data 
streain is spread. The latter, the number of interleaved 
packets over which the data stream is spread, is called the 

interleave window. > 

To create a packet, the jransmittind software interleaves 
the normal IP packets 207a et. seq. to torm a new set^ 
m terleaved payload data 320. This payload data 320 is then 
encrypted using a session Key to form a set of session-key- 
encrypted payload data 330, each of which. A, B, and C, will 
fornrthe^ayload of a TARP packet. Using the IP header 
data, from the original packets 207fl-207c, new TARP 
headers' IPj- are formed. The TARP headers IPy- can be 
identical to normal IP headers or customized in some way. 
In a preferred embodiment, the TARP headers IPj- are IP 
headers with added data providing the following information 
required for routing and reconstruction of messages, some of 
which data is ordinarily, or capable of being, contained in 
normal IP headers: 




30 



35 



40 



50 



55 



A window sequence numb er — an identifier that indi- 
cates where me packeT belongs in the original message 
sequence. 

An interleave ^giipnrj^ niimhei^an identifier that 

indicates the interleaving sequence used to form the 
packet so that the packet can be deinterleaved along 
with other packets in the interleave window. 
A time-to -live (TTL) datum — indicates the number of 
TARP-router-hops to be executed before the packet 
reaches its destination. Note that the TTL parameter 
may provide a datum to be used in a probabilistic 
formula for determining whether to route the packet to 
the destination or to another hop. 
Data type identifier — indicates whether the payload 
contains, for example, TCP or UDP data. 
Sender's address — indicates the sender's address in the 
TARP network. 



65 



6. Destination address — indicates the destination termi- 
nal's address in the TARP network. 

7. Decoy/Real — an indicator of whether the packet con- 
tains real message data or dummy decoy data or a 
combination. 

Obviously, the packets going into a single interleave 
window must include only packets with a common destina- 
tion. Thus, it is assumed in the depicted example that the IP 
headers of IP packets 207fl-207c all contain the same 
destination address or at least will be received by the same 
terminal so that they can be deinterleaved. Note that dummy 
or decoy data or packets can be added to form a larger 
interleave window than would otherwise be required by the 
size of a given message. Decoy or dummy data can be added 
to a stream to help foil traflSc analysis by leveUng the load 
on the network. Thus, it may be desirable to provide the 
TARP process with an ability to respond to the time of day 
or other criteria to generate more decoy data during low 
trafSc periods so that communication bursts at one point in 
the Intemet cannot be tied to communication bursts at 
another point to reveal the communicating endpoints. 

Dummy data also helps to break the data into a larger 
number of inconspicuously-sized packets permitting the 
interleave window size to be increased while maintaining a 
reasonable size for each packet. (The packet size can be a 
single standard size or selected firom a fixed range of sizes.) 
One primary reason for desiring for each message to be 
broken into multiple packets is apparent if a chain block 
encryption scheme is used to form the first encryption layer 
prior to interleaving. A single block encryption may be 
applied to a portion, or the entirety, of a message, and that 
portion or entirety then interleaved into a number of separate 
packets. 

Referring to FIG. 3Z>, in an alternative mode of TARP 
packet construction, a scries of IP packets are accumulated 
tojnake iip ^ predefi ned interleave window. The payloads of 
the packets are used to construct a single block 520 for chain 
block encryption using the session key. The payloads used to 
form the block are presumed to be destined for the same 
terminal. The block size may coincide with the interleave 
window as depicted in the example embodiment of FIG. 3£?. 
After encryption, the encrypted block is broken into separate 
payloads and segments which are interleaved as in the 
embodiment of FIG. 3fl. T he resulting interleaved packets A , 
B, and C, are then packaged as TARP packets with TARP 
he aders as in the Example of FIG.^a . The remaining process 
IS" as stiown in, and discussed with reference to, FIG. 3fl. 

Once the TARP packets 340 are formed, each entire TARP 
packet 340, including the TARP header IPj-, is encrypted 
using the link key for communication with the first-hop- 
TARP router. The first hop TARP router is randomly chosen. 
A final unencrypted IP header IP^- is added to each encrypted ^ 
TARP packet 340 to form a normal IP packet 360 that caa^ -q>TOt/><»yv>fcL 
be t ransmitted to a TARP router . Note that the process of 
constmcting the TARP packet 360 does not have to be done 
in stages as described. The above description is just a useful 
heuristic for describing the final product, namely, the TARP 
packet. 

Note that, TARP header I Pj- could be a completely custom 
header configm-ation with no similarity to a normal IP header 
except that it contain the information identified above. This 
is so since this header is interpreted by only TARP routers. 

The above scheme may be implemented entirely by 
processes operating between the data link layer and the 
network layer of each server or terminal participating in the 
TARP system. Referring to FIG. 4, a TARP transceiver 405 
can be an originating terminal 100, a destination terminal 
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110, o r a TARP router 122-1 27. In each TARP Transceiver of TARP routers on any given subnet is expected to be 

(5- - 4 05, a/ tFftnsmitting proces^is generated to receive norma l relatively small, this process of updating the LUTs should be 

packets ^om the Network (IP) layer and generate T ARP relatively fast. It may not, however, work as well when there 

packets^tor communication over the network . A fecemn g^ ^ a relatively large number of TARP routers and/or a 

'fcrocess]s gene rated to receive normal IP packets containin g 5 relatively large number of clients; this has motivated a 

' ISUP packets and generate from these normal IP packe ts refinement of this architecture to provide scalability; this 

which are "passed up" to tbe Network W) layer . Note that refinement has led to a second embodiment, which is dis- 

where the TARP Transceiver 405 is a router, the received cussed below. 

TARP packets 140 are not processed into a stream of IP Upo° detection of an attack, the TARP process may al" 

packets 415 because they need only be authenticated as lo create a subprocess that maintains the original IP address 

proper TARP packets and the n passed t o another TARP continues interacting with the attacker. The latter may 

router or a TARP destination terminal llD. The intervening provide an opportunity to trace the attacker, or study the 

process, a "TARP Layer" 420, could be combined with attacker's methods (called "fishbowling" drawing upon the 

either the data link layer 430 or the Network layer 410. In analogy of a small fish in a fish bowl that "thinks" it is in the 

either case, it would intervene between the data link layer 15 ocean but is actually under captive observation). A history of 

430 so that the process would receive regular IP packets the communication between the attacker and the abandoned 

containing embedded TARP packets and "hand up" a series (fishbowled) IP address can be recorded or transmitted for 

of reassembled IP packets to the Network layer 410. As an human analysis or further synthesized for purposes of 

example of combining the TARP layer 420 with the data link responding in some way. 

layer 430, a program may augment the normal processes 20 As mentioned above, decoy or dummy data or packets can 

running a communications card, for example, an Ethernet be added to outgoing data streams by TARP terminals or 

card. Alternatively, the TARP layer processes may form part routers. In addition to making it convenient to spread data 

of a dynamically loadable module that is loaded and over a larger number of separate packets, such decoy packets 

executed to support commimicalions between the network can also help to level the load on inactive portions of the 

and data link layers. 25 Internet to help foil trafBc analysis efforts. 

Because the encryption system described above can be Decoy packets may be generated by each TARP terminal 

inserted between the data link and network layers, the 1^0' or each router 122-127 on some basis determined 

processes involved in supporting the encrypted communi- an algorithm. For example, the algorithm may be a 

cation may be completely transparent to processes at the IP random one which calls for the generation of a packet on a 

(network) layer and above. The TARP processes may also be 30 random basis when the terminal is idle. Alternatively, the 

completely transparent to the data link layer processes as algorithm may be responsive to time of day or detection of 

well. Thus, no operations at or above the network layer, or low trj^Qc to generate more decoy packets during low traffic ^ 

at or below the data link layer, are affected by the insertion times/Note that packets are preferably generated in groups, ( 

of the TARP stack. This provides additional security to all rathetnEan one by one, the groups being sized to simulate J 

processes at or above the network layer, since the diflScuhy 35 real messages/In addition, so that decoy packets may be 

of unauthorized penetration of the network layer (by, for inserted in normal TARP message streams, the background 

example, a hacker) is increased substantially. Even newly loop may have a latch that makes it more likely to insert 

developed servers running at the session layer leave all decoy packets when a message stream is being received, 

processes below the session layer vulnerable to attack. Note That is, when a series of messages are received, the decoy 

that in this architecture, security is distributed. That is, 40 packet generation rate may be increased. Alternatively, if a 

notebook computers used by executives on the road, for large number of decoy packets is received along with regular 

example, can communicate over the Internet without any TARP packets, the algorithm may increase the rate of 

compromise in security. dropping of decoy packets rather than forwarding them. The 

Note that IP address changes made by TARP terminals result of dropping and generating decoy packets in this way 

and routers can be done at regular intervals, at random 45 is to make the apparent incoming message size different 

intervals, or upon detection of "attacks." The variation of IP ^om the apparent outgoing message size to help foil traffic 

addresses hinders traffic analysis that might reveal which analysis. The rate of reception of packets, decoy or 

computers are communicating, and also provides a degree of otherwise, may be indicated to the decoy packet dropping 

immunity from attack. The level of immunity from attack is and generating processes through perishable decoy and 

roughly proportional to the rate at which the IP address of so regular packet counters. (A perishable counter is one that 

the host is changing. resets or decrements its value in response to lime so that it 

As mentioned, IP addresses may be changed in response contains a high value when, it is incremented in rapid 

to attacks. An attack may be revealed, for example, by a succession and a small value when incremented either 

regular series of messages indicates that a router is being slowly or a small number of times in rapid succession.) Note 

probed in some way. Upon detection of an attack, the TARP 55 that destination TARP terminal UO may generate decoy 

layer process may respond to this event by changing its IP packets equal in number and size to those TARP packets 

address. To accomplish this, the TARP process will construct received to make it appear it is merely routing packets and 

a TARP-formatted message, in the style of Internet Control is therefore not the destination terminal. 

Message Protocol (ICMP) datagrams as an example; this Referring to FIG. 5, the foUowing particular steps may be 

message will contain the machine^ TARP address, its 60 employed in the above-described method for routing TARP 

previous IP address, and its new IP address. The TARP layer packets. 

will transmit this packet to at least one known TARP router; SO. A background loop operation is performed which 

then upon receipt and validation of the message, the TARP applies an algorithm which determines the generation 

router will update its LUT with the new IP address for the of decoy IP packets. The loop is interrupted when an 

stated TARP address. The"TARP router will then format a 65 encrypted TARP packet is received, 

similar message, and broadcast it to the other TARP routers S2. The TARP packet may be probed in some way to 

so that they may update their LUTs. Since the total number authenticate the packet before attempting to decrypt it 
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using the link key. That is, the router may determine 
that the packet is an authentic TARP packet by per- 
forming a selected operation on some data included 
with the clear IP header attached to the encrypted TARP 
packet contained in the payload. This makes it possible 
to avoid performing decryption on packets that are not 
authentic TARP packets. 

53. The TARP packet is decrypted to expose the destina- 
tion TARP address and an indication of whether the 
packet is a decoy packet or part of a real message, 

54. If the packet is a decoy packet, the perishable decoy 
counter is incremented. 

55. Based on the decoy generation/dropping algorithm 
and the perishable decoy counter value, if the packet is 
a decoy packet, the router may choose to throw it away. 
If the received packet is a decoy packet and it is 
determined that it should be thrown away (S6), control 
returns to step SO. 

57. The TTL parameter of the TARP header is decre- 
mented and it is determined if the TTL parameter is 
greater than zero. 

58. If the TTL parameter is greater than zero, a TARP 
address is randomly chosen from a list of TARP 
addresses maintained by the router and the link key and 25 
IP address corresponding to that TARP address memo- 
rized for use in creating a new IP packet containing the 
TARP packet. 

59. If the TTL parameter is zero or less, the link key and 

IP address corresponding to the TARP address of the 30 
destination are memorized for use in creating the new 
IP packet containing the TARP packet. 
SIO. The TARP packet is encrypted using the memorized 
link key. 

SI 1. An IP header is added to the packet that contains the 
stored IP address, the encrypted TARP packet wrapped 
with an IP header, and the completed packet transmitted 
to the next hop or destination. 
Referring to FIG. 6, the following particular steps may be 
employed in the above-described method for generating 
TARP packets. 
S20. A background loop operation applies an algorithm 
that determines the generation of decoy IP packets. The 
loop is interrupted when a data stream containing IP 
packets is received for transmission. 
S2L The received IP packets are grouped into a set 
consisting of messages with a constant IP destination 
address. The set is further broken down to coincide 
with a maximum size of an interleave window The set 
is encrypted, and interleaved into a set of payloads 
destined to become TARP packets. 
S22. The TARP address corresponding to the IP address is 
determined from a lookup table and stored to generate 
the TARP header. An initial TTL count is generated and 
stored in the header. The TTL count may be random 
with minimum and maximum values or it may be fixed 
or detejTuined by some other parameter. 
"S2I 



The window sequence numbers and interleave 
sequence numbers are recorded in the TARP headers 
_each packet^ 

S24. One TARP router address is randomly chosen for 



ave J 



each TARP packet and the IP address corresponding to 
it stored for use in the clear IP header. The link key 
corresponding to this router is identified and used to 65 
encrypt TARP packets containing interleaved and 
encrypted data and TARP headers. 



40 



45 
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S25. A clear IP header with the first hop router's real IP 
address is generated and added to each of the encrypted 
TARP packets and the resulting packets. 

Referring to FIG. 7, the following particular steps may be 
employed in the above-described method for receiving 
TARP packets. 

S40. A background loop operation is performed which 
applies an algorithm which determines the generation 
of decoy IP packets. The loop is interrupted when an 
encrypted TARP packet is received. 

542. The TARP packet may be probed to authenticate the 
packet before attempting to decrypt it using the hnk 
key. 

543. The TARP packet is decrypted with the appropriate 
link key to expose the destination TARP address and an 
indication of whether the packet is a decoy packet or 
part of a real message. 

544. If the packet is a decoy packet, the perishable decoy 
counter is incremented, 

545. Based on the decoy generation/dropping algorithm 
and the perishable decoy counter value, if the packet is 
a decoy packet, the receiver may choose to throw it 
away. 

546. The TARP packets are cached until all packets 
forming an interleave window are received, 

547. Once all packets of an interleave window are 
received, the packets are deinterleaved, 

548. ITie packe ts hlnyjf nf combined packets defining the 
interleave window is then decrypted using the session 
key. 

549. The decrypted block is then divided using the 
window sequence data and the IP7. headers are con- 
verted into normal IP^: headers. The window sequence 
numbers are integrated in the IP^^ headers, 

550. The packets are then handed up to the IP layer 
processes. 

1. SCALABILITY ENHANCEMENTS 

The IP agility feature described above relies on the ability 
to transmit IP address changes to all TARP routers. The 
embodiments including this feamre will be referred to as 
"boutique" embodiments due to potential limitations in 
scaling these features up for a large network, such as the 
Internet, (The "boutique" embodiments would, however, be 
robust for use in smaller networks, such as small virtual 
private networks, for example). One problem with the 
boutique embodiments is that if IP address changes are to 
occur frequently, the message trafiSc required to update all 
routers suflBciently quickly creates a serious burden on the 
Internet when the TARP router and/or client population gets 
large. The bandwidth burden added to the networks, for 
example in ICMP packets, that would be used to update all 
the TARP routers could overwhelm the Internet for a large 
scale implementation that approached the scale of the Inter- 
net. In other words, the boutique system's scalabiUty is 
Umited. 

A system can be constructed which trades some of the 
features of the above embodiments to provide the benefits of 
IP agility without the additional messaging burden. This is 
accomplished by IP address-hopping according to shared 
algorithms that govern IP addresses used between links 
participating in communications sessions between nodes 
such as TARP nodes. (Note that the IP hopping technique is 
also applicable to the boutique embodiment.) The IP agility 
feamre discussed with respect to the boutique system can be 
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modified so that it becomes decentralized under this scalable 
regime and governed by the above-described shared algo- 
rithm. Other features of the boutique system may be com- 
bined with this new type of IP-agility. 

The new embodiment has the advantage of providing IP 
agility governed by a local algorithm and set of IP addresses 
exchanged by each communicating pair of nodes. This local 
governance is session-independent in that it may govern 
communications between a pair of nodes, irrespective of the 
session or end points being transferred between the directly ^* 
commimicating pair of nodes. 

In the scalable embodiments, blocks of IP addresses are 
allocated to each node in the network. (This scalability will 
increase in the future, when Internet Protocol addresses are 
increased to 128-bit fields, vastly increasing the number of 
distinctly addressable nodes). Each node can thus use any of 
the IP addresses assigned to that node to communicate with 
other nodes in the network. Indeed, each pair of communi- 
cating nodes can use a plurality of source IP addresses and 
destination IP addresses for communicating with each other. 

Each communicating pair of nodes in a chain participating 
in any session stores two blocks of IP addresses, called 
netblocks , and an algorithm and randomization seed for 
selecting,^ fi*om each netblock, the next pair of source/ 25 



exp 
bTl 



destination IP addresses that will be used to transmit the next 
message. In other words, the algorithm governs the sequen- 
tial selection of IP- address pairs, one sender and one 
receiver IP address, from each netblock. The combination of 
algorithm, seed, and netblock (IP address block) will be 
called a "hopblock." A router issues separate transmit and 
receive hopb locks to its clients. The send address and the 
receive address of the IP header of each outgoing packet sent 
by the client are filled with the send and receive IP addresses 
generated by the algorithm. The algorithm is "clocked" 
(indexed) by a counter so that each time a pair is used, the 
algorithm turns out a new transmit pair for the next packet 
to be sent. 

The router's receive hopblock is identical to the cfient's 
transmit hopblock. The route r uses the receive hopblock to 40 
pr edict what the send and receive ir addfgSfe pair ror th e next 
greeted packet ffom that client will be. Since packets caff 
be received out of order, it is not possible for the router to 
predict with certainty what IP address pair will be on the 
nex [ sequential packet . To account for this problem, the 45 
router generates a range of predictions encompassing the 
number of possible transmitted packet send/receive 
addresses, of which the next packet received could leap 
ahead. Thus, if there is a vanishingly small probability that 
a given packet will arrive at the router ahead of 5 packets 50 
transmitted by the client before the given packet, then the 
router can generate a se ries of 6 sen d/receive IP address pairs 
(or "hop window") toj^comparel wi t h the next received 
^Q ^ t. When a_ packeris receiyed, JT^ 'nTariggg'rfrtBgTISp 
window as such, so that a second packet with the same IP 55 
address pair will be discarded. If an out-of-sequence packet 
does not arrive within a predetermined timeout period, it can 
be requested for retransmission or simply discarded from the 
receive table, depending upon the protocol in use for that 
communications session, or possibly by convention. 

When the router receives the client's packet, it compares 
the send and receive IP addresses of the packet with the next 
N predicted send and receive IP address pairs and rejects the 
packet if it is not a member of this set. Received packets that 
do not have the predicted source/destination IP addresses 65 
falling with the window are rejected, thus thwarting possible 
ackers. (With the number of possible combinations, even a 



fairly large window would be hard to fall into at random.) If 
it is a member of this set, the router accepts the packet and 
processes it further. This link-based IP-hopping strategy, 
referred to as "IHOP," is a network element that stands on 
its own and is not necessarily accompanied by elements of 
the boutique system described above. If the routing agility 
feature described in connection with the boutique embodi- 
ment is combined with this link-based IP-hopping strategy, 
the router's next step would be to decrypt the TARP header 
to determine the destination TARP router for the packet and \ 
determine what should be the next hop for the packet. The ] 
TARP router would then ^jcKaid the packet to a random / 
TARP router or the destination TARP router with which the / 
source TARP router has a link-based IP hopping communi- / 
[Cation established. ^ 

FIG. 8 shows how a client computer 801 and a TARP 
router 811 can establish a secure session. When client 801 
seeks to establish an IHOP session with TARP router 811, 
the client 801 sends "secure synchronization" request 
("SSYN") packet 821 to the TARP router 811. This SYN 
packet 821 contains the client's 801 authentication token, 
and may be sent to the router 811 in an encrypted format. 
The source and destination IP numbers on the packet 821 are 
the client's 801 current fixed IP address, and a "known" 
fixed IP address for the router 811. (For secur ity purposes, 
it may be desirable to reject any packeis rrom ouisi je of the 
^ 1o<ga'Detw<a lgmt*gfe^gt1^ tbr'trie rduter^s known tixe^ 
Wd'dr?sS/Op??n're^ 

Vpacket 821, the router 811 responds by sending an 
encrypted "secure synchronization acknowledgment" 
("SSYN ACK") 822 to the cHent 801. This SSYN ACK 822 
will contain the transmit and receive hopblocks that the 
client 801 will use when communicating with the TARP 
router 811. The client 801 will acknowledge the TARP 
router's 811 response packet 822 by generating an encrypted 
SSYN ACK ACK packet 823 which will be sent from the 
client's 801 fixed IP address and to the TARP router's 811 
known fixed IP address. The client 801 will simultaneously 
generate a SSYN ACK ACK packet; this SSYN ACK 
packet, referred to as the Secure Session Initiation (SSI) 
packet 824, will be sent with the first {sender, receiver} IP 
pair in the client's transmit table 921 (FIG. 9), as specified 
in the transmit hopblock provided by the TARP router 811 
in the SSYN ACK packet 822. The TARP router 811 will 
respond to the SSI packet 824 with an SSI ACK packet 825, 
which will be sent with the first {sender, receiver} IP pair in 
the TARP router's transmit table 923. Once these packets 
have been successfully exchanged, the secure communica- 
tions session is established, and all further secure commu- 
nications between the client 801 and the TARP router 811 
will be conducted via this secure session, as long as syn- 
chronization is maintained. If synchronization is lost, then 
the client 801 and TARP router 802 may re-establish the 
secure session by the procedure outlined in FIG. 8 and 
described above. 

While the secure session is active, both the client 901 and 
TARP router 911 (FIG. 9) will maintain t^eir respective 
^nsmit tables 921, 923^nd receive tabies ^922, 924r^ 
provided by the J'AUp router during session synchronization 
822. It is important that the ^sequence of IP pa"^ in the 
client' s transmit table 921 be identical to those in the TARP 
router's receive table 9 24; similarly, the sequence of IP pairs 
in the client's receivelable 922 must be identical to those in 
the router's transmit table 923. This is required for the 
session synchronization to be maintained. The client 901 
need maintain only one transmit table 921 and one receive 
table 922 during the course of the secure session. Each 
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sequential packet sent by the client 901 will employ the next the range covering the allowed IP addresses with a given 

{send, receive} IP address pair in the transmit table, regard- seed. Alternatively, the session participants can assume a 

less of TCP or UDP session. The TARP router 911 will certain type of algorithm and specify simply a parameter for 

expect each packet arriving from the cUent 901 to bear the applying the algorithm. For example the assumed algorithm 

next IP address pair shown in its receive table. 5 could be a particular pseudo-random number generator and 

Since packets can arrive out of order, however, the router the session participants could simply exchange seed values. 

911 can maintain a "look ahead" buffer in its receive table, j^^,^ .u,. .t,^„ • „^ ♦ u 1 ^* *• r 

J -11 1 . I ■ J • • 1-j r Note that there is no permanent physical distinction 

and will mark previously- received IP pairs as mvalid for , * *u • • j j * • 1 j 

ft , 1 ♦ A 1 * * • • Tn • *i_ * between the origmating and destmation termmal nodes, 

future packets any future packet contammg an IP pair that , . , \, j • . • . • 

- . ♦uiiu juo- u*' ij • 1 Either device at either end point can imtiate a synchroniza- 

is m the look-ahead butter but is marked as previously m r *t- • xt * 1 . .x. 

received wiU be discarded. Communications from the TARP '^\?'''- Note also that the authentication/ 

router 911 to the client 901 are maintained in an identical synchronization-request (and acknowledgment) and 

manner; in particular, the router 911 will select the next IP hopblock-exchange may all be served by a single message 

address pair from its transmit table 923 when constructing a ^"P^^^^^ "^^^ 

packet to send to the client 901, and the client 901 will ^5 ^ another extension to the stated architecture, multiple 

maintain a look-ahead buffer of expected IP pairs on packets physical paths can be used by a cUent, in order to provide 

that it is receiving. Each TARP router will maintain separate redundancy and further thwart attempts at denial of 

pairs of transmit and receive tables for each client that is service and traffic monitoring. As shown in FIG. 10, for 

currently engaged in a secure session with or through that example, client 1001 can establish three simultaneous ses- 

TARP router ^^^^ ^^^^ °f ^^^^^ TARP routers provided by different 

WhUe clients receive their hopblocks from the first server '° ^^^^ 1^^^'}!P^ ^ ^° ^^^PI^A^^^ ^^.V^ 

Unking them to the Internet, routers exchange hopblocks. ^^'^^ ^f^^f^l, ^^^^P*^^"^ ^""^l 1^21, 1022 1023 to 

When a router estabUshes a hnk-based IP-hopping commu- ^^^^^ telephone hnes and a cable 

nication regime with another router, each router of the pair J° transmitted packets will be sent 

exchanges its transmit hopblock. The transmit hopblock of ,5 ^^^^^^ P^^y^ical paths. This 

each router becomes the receive hopblock of the other architecture provides a high degree of communications 

router. The communication between routers is governed as redundancy, with improved immunity from denial-of- 

described by the example of a cHent sending a packet to the ^^^^ '"^^^ monitormg. 

^'^ilT^^: . , ^ . . ^ ... 2. FURTHER EXTENSIONS 

While the above strategy works fine in the IP miheu, 30 

many local networks that are connected to the Internet are The following describes various extensions to the 

Ethernet systems. In Ethernet, the IP addresses of the techniques, systems, and methods described above. As 

destination devices must be translated into hardware described above, the security of communications occurring 

addresses, and vice versa, using known processes ("address between computers in a computer network (such as the 

resolution protocol," and "reverse address resolution 35 Internet, an Ethernet, or others) can be enhanced by using 

protocol"). However, if the link-based IP-hopping strategy is seemingly random source and destination Internet Protocol 

employed, the correlation process would become explosive (IP) addresses for data packets transmitted over the network. 

and burdensome. An ahemative to the link-based IP hopping This feature prevents ^ca ve sdr qiJp ers^from^^ 

strategy may be employed within an Ethernet network. The wliicii computersjn^be^^ 

solution is to provide that the node linking the Internet to the 40 j^^^her wmleperadtting the twojcommun^Hm^ 



Ethernet (call it the border node) use the link-based puters to easily^jgpgg nize^\yhether^ a. giv en ^received oa^ 
IP-hopping communication regime to communicate with gacKef^is^le giti^ or xot.. In one embodiment of tSe* 
nodes outside the Ethernet LAN. Within the Ethernet LAN, a£ove-descri5e3 systems, an IP header extension field is, 
each TARP node would have a single IP address which used to authenticate incoming packets on an Ethernet, 
would Ja fr^addressed in the conventional way. Instead of 45 Various extensions to the previously described techniques 
rcomparin^the {sender, receiver) IP address pairs to authen- described herein include: (1) use of hopped hardware or 
ncaie^jgac ket^^ mtra-LAM' lARP node would use one of "MAC addresses in broadcast type network; (2) a self- 
the iP header extension fields to do so. Thus, the border node synchronization technique that permits a computer to auto- 
uses an algorithm shared by the intra-LAN TARP node to matically regain synchronization with a sender; (3) synchro - 
generate a symbol that is stored in the free field in the IP 50 nization algorithms that allow transmitting and receiving 
header, and the intra-LAN TARP node generates a range of computers to quickly re-estabUsh synchronization in the 
symbols based on its prediction of the next expected packet event of lost packets or other events; and (4) a fast-packet 
to be received from that particular source IP address. The rejection mechanism for rejecting invalid packets. Any or all 
packet is rejected if it does not fall into the set of predicted of these extensions can be combined with the features 
symbols (for example, numerical values) or is accepted if it 55 described above in any of various ways, 
does. Communications from the intra-LAN TARP node to A. Hardware Address Hopping 

the border node are accomplished in the same manner, Internet protocol-based communications techniques on a 

though the algorithm will necessarily be different for secu- LAN — or across any dedicated physical medium — typically 

rity reasons. Thus, each of the communicating nodes will embed the IP packets within lower-level packets, often 

generate transmit and receive tables in a similar manner to 60 referred to as "frames." As shown in FIG. U, for example, 

that of FIG. 9; the intra-LAN TARP nodes transmit table will a first Ethernet frame 1150 comprises a frame header 1101 

be identical to the border, node's receive table, and the and two embedded IP packets IPl and IP2, while a second 

intra-LAN TARP node's receive table will be identical to the Ethernet frame 1160 comprises a different frame header 

border node's transmit table. 1104 and a single IP packet IP3. Each frame header gener- 

The algorithm used for IP address-hopping can be any 65 ally includes a source hardware address IIOIA and a des- 

desired algorithm. For example, the algorithm can be a given tination hardware address IIOIB; other well-known fields in 

pseudo-random number generator that generates numbers of frame headers are omitted from FIG. 11 for clarity. Two 
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hardware nodes communicating over a physical communi- packets or "secure communications" to differentiate them 

cation channel insert appropriate source and destination from ordinary data packets that are transmitted in the clear 

hardware addresses to indicate which nodes on the channel using ordinary, machine-correlated addresses. — 

or network should receive the frame. One straightforward method of generating non- \ 

It may be possible for a nefarious listener to acquire 5/ attributable MAC addresses is an extension of the IP hop- \ 

information about the contents of a frame and/or its com- / ping scheme. In this scenario, two machines on the same I 

municants by examining frames on a local network rather I LAN that desire to communicate in a secure fashion I 

than (or in addition to) the IP packets themselves. This is I exchange random-number generators and seeds, and create / 

especially true in broadcast media, such as Ethernet, where I sequences of quasi-random MAC addresses for synchro- / 

it is necessary to insert into the frame header the hardware la nized bopping. The implementation and synchronization / 

address of the machine that generated the frame and the \ issues are then similar to that of IP hopping. 

hardware address of the machine to which frame is being This approach, however, runs the risk of using MAC 

sent. All nodes on the network can potentially "see" all addresses that are currently active on the LAN — which, in 

packets transmitted across the network. This can be a turn, could interrupt communications for those machines, 

problem for secure communications, especially in cases 15 Since an Ethernet MAC address is at present 48 bits in 

where the communicants do not want for any third party to length, the chance of randomly misusing an active MAC 

be able to identify who is engaging in the information address is actually quite small. However, if that figure is 

exchange. One way to address this problem is to push the multipUed by a large number of nodes (as would be found 

address-hopping scheme down to the hardware layer. In on an extensive LAN), by a large number of frames (as 

accordance with various embodiments of the invention, 20 might be the case with packet voice or streaming video), and 

hardware addresses are "hopped" in a manner similar to that by a large number of concurrent \^rtual Private Networks 

used to change IP addresses, such that a listener cannot (VPNs), then the chance that a non -secure machine's MAC 

determine which hardware node generated a particular mes- address could be used in an address-hopped frame can 

sage nor which node is the intended recipient. become non-trivial. In short, any scheme that runs even a 

FIG. 12A shows a system in which Media Access Control 25 small risk of interrupting communications for other 

("MAC") hardware addresses are "hopped" in order to machines on the LAN is bound to receive resistance from 

increase security over a network such as an Ethernet. While prospective system administrators. Nevertheless, it is tech- 

the description refers to the exemplary case of an Ethernet nically feasible, and can be implemented without risk on a 

environment, the inventive principles are equally applicable LAN on which there is a small number of machines, or if all 

to other types of communications media. In the Ethernet 30 of the machines on the LAN are engaging in MAC-hopped 

case, the MAC address of the sender and receiver are communications. 

inserted into the Ethernet frame and can be observed by Synchronized MAC address hopping may incur some 

anyone on the LAN who is within the broadcast range for overhead in the course of session establishment, especially 

that frame. For secure communications, it becomes desirable if there are multiple sessions or multiple nodes involved in 

to generate frames with MAC addresses that are not attrib- 35 the communications. A simpler method of randomizing 

utable to any specific sender or receiver. MAC addresses is to allow each node to receive and process 

As shown in FIG. 12 A, two computer nodes 1201 and every incident frame on the network. Typically, each net- 

1202 communicate over a communication channel such as work interface driver will check the destination MAC 

an Ethernet. Each node executes one or more application address in the header of every incident frame to see if it 

programs 1203 and 1218 that communicate by transmitting 40 matches that machine's MAC address; if there is no match, 

packets through communication software 1204 and 1217, then the frame is discarded. In one embodiment, however, 

respectively. Examples of appUcation programs include these checks can be disabled, and every incident packet is 

video conferencing, e-mail, word processing programs, passed to the TARP stack for processing. This will be 

telephony, and the like. Communication software 1204 and referred to as "promiscuous" mode, since every incident 

1217 can comprise, for example, an OSI layered architecture 45 frame is processed. Promiscuous mode allows the sender to 

or "stack" that standardizes various services provided at use completely random, unsynchronized MAC addresses, 

different levels of functionality. since the destination machine is guaranteed to process the 

The lowest levels of communication software 1204 and frame. The decision as to whether the packet was truly 

1217 communicate with hardware components 1206 and intended for that machine is handled by the TARP stack, 

1214 respectively, each of which can include one or more 50 which checks the source and destination IP addresses for a 

registers 1207 and 1215 that allow the hardware to be match in its IP synchronization tables. If no match is found, 

reconfigiired or controlled in accordance with various com- the packet is discarded; if there is a match, the packet is 

munication protocols. The hardware components (an Ether- unwrapped, the inner header is evaluated, and if the inner 

net network interface card, for example) communicate with header indicates that the packet is destined for that machine 

each other over the communication medium. Each hardware 55 then the packet is forwarded to the IP stack — otherwise it is 

component is typically pre-assigned a fixed hardware discarded. 

address or MAC number that identifies the hardware com- One disadvantage of purely-random MAC address hop- 
pone nt to other nodes on the network. One or more interface ping is its impact on processing overhead; that is, since 
drivers control the operation of each card and can, for every incident frame must be processed, the machine *s CPU 
example, be configured to accept or reject packets from 60 is engaged considerably more often than if the network 
certain hardware addresses. As will be described in more interface driver is discriminating and rejecting packets uni- 
detail below, various embodiments of the inventive prin- laterally. A compromise approach is to select either a single 
ciples provide for "hopping" different addresses using one or fixed MAC address or a small number of MAC addresses 
more algorithms and one or more moving windows that (e.g., one for each virtual private network on an Ethernet) to 
track a range of valid addresses to validate received packets. 65 use for MAC-hopped communications, regardless of the 
Packets transmitted according to one or more of the inven- actual recipient for which the message is intended. In this 
tive principles will be generally referred to as "secure" mode, the network interface driver can check each incident 
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frame against one (or a few) pre-established MAC 
addresses, thereby freeing the CPU from the task of 
physical-layer packet discrimination. This scheme does not 
betray any useful information to an interloper on the LAN; 
in particular, every secure packet can already be identified 
by a unique packet type in the outer header. However, since 
all machines engaged in secure communications would 
either be using the same MAC address, or be selecting from 
a small pool of predetermined MAC addresses, the associa- 
tion between a specific machine and a specific MAC address 
is effectively broken. 

In this scheme, the CPU will be engaged more often than 
it would be in non-secure commimications (or in synchro- 
nized MAC address hopping), since the network interface 
driver cannot always unilaterally discriminate between 
secure packets that are destined for that machine, and secure 
packets from other VPNs. However, the non-secure traffic is 
easily eliminated at the network interface, thereby reducing 
the amount of processing required of the CPU. There are 
boundary conditions where these statements would not hold, 
of course-e.g., if all of the trafiSc on the LAN is secure traffic, 
then the CPU would be engaged to the same degree as it is 
in the purely-random address hopping case; alternatively, if 
each VPN on the LAN uses a different MAC address, then 
the network interface can perfectly discriminate secure 
frames destined for the local machine from those constitut- 
ing other VPNs. These are engineering tradeoffs that might 
be best handled by providing administrative options for the 
users when installing the software and/or establishing VPNs. 

Even in this scenario, however, there still remains a slight 
risk of selecting MAC addresses that are being used by one 
or more nodes on the LAN. One solution to this problem is 
to formally assign one address or a range of addresses for 
use in MAC-hopped communications. This is typically done 
via an assigned numbers registration authority; e.g., in the 
case of Ethernet, MAC address ranges are assigned to 
vendors by the Institute of Electrical and Electronics Engi- 
neers (IEEE). A formally-assigned range of addresses would 
ensure that secure frames do not conflict with any properly- 
configured and properly-functioning machines on the LAN. 

Reference will now be made to FIGS. 12A and 12B in 
order to describe the many combinations and features that 
follow the inventive principles. As explained above, two 
computer nodes 1201 and 1202 are assumed to be commu- 
nicating over a network or communication medium such as 
an Ethernet. A communication protocol in each node (1204 
and 1217, respectively) contains a modified element 1205 
and 1216 that performs certain functions that deviate from 
the standard communication protocols. In particular, com- 
puter node 1201 implements a first "hop" algorithm 1208X 
that selects seemingly random source and destination IP 
addresses (and, in one embodiment, seemingly random IP 
header discriminator fields) in order to transmit each packet 
to the other computer node. For example, node 1201 main- 
tains a transmit table 1208 containing triplets of source (S), 
destination (D), and discriminator fields (DS) that are 
inserted into outgoing IP packet headers. The table is gen- 
erated through the use of an appropriate algorithm (e.g., a 
random number generator that is seeded with an appropriate 
seed) that is known to the recipient node 1202. As each new 
IP packet is formed, the next sequential entry out of the 
sender's transmit table 1208 is used to populate the IP 
source, IP destination, and IP header extension field (e.g., 
discriminator field). It will be appreciated that the transmit 
table need not be created in advance but could instead be 
created on-the-fly by executing the algorithm when each 
packet is formed. 
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At the receiving node 1202, the same IP hop algorithm 
1222X is maintained and used to generate a r eceive ta ble 
122 2that lists valid jriplets of sourc e IP address, ' destinaSSn* 
IP adgress, a nd disc riminator iGSi3!^ snowcrBy^jftire^ 

5 thefirernve entries" or Iransminable 1208 matching the 
second five entries of receive tabl e 1222. (T he tables may be 
slightly ofifeet at any particular ttimc duet t o lost packe d — 
misordered packets, or transmission delays). Additionally, 
node 1202 maintains a receive window W3 that represents 

10 a list of valid IP source, IP destination, and discriminator 
fields that will be accepted when received as part of an 
incoming IP packet. As packets are received, window W3 
slides down the list of valid entries, such that the possible 
valid entries change over time. Two packets that arrive out 

15 of order but are nevertheless matched to entries within 
window W3 will be* accepted; those falling outside of 
window W3 will be rejected as invalid. The length of 
window W3 can be adjusted as necessary to reflect network 
delays or other factors. 

20 Node 1202 maintains a similar transmit table 1221 for 
creating IP packets and frames destined for node 1201 using 
a potentiaUy different hopping algorithm 1221X, and node 
1201 maintains a matching receive table 1209 using the 
same algorithm 1209X. As node 1202 transmits packets to 

25 node 1201 using seemingly random IP source, IP 
destination, and/or discriminator fields, node 1201 matches 
the incoming packet values to those falling within window 
WI maintained in its receive table. In effect, transmit table 
1208 of node 1201 is synchronized (i.e., entries are selected 

30 in the same order) to receive table 1222 of receiving node 
1202. Similarly, transmit table 1221 of node 1202 is syn- 
chronized to receive table 1209 of node 1201. It will be 
appreciated that although a common algorithm is shown for 
the source, destination and discriminator fields in FIG. 12A 

35 (using, e.g., a different seed for each of the three fields), an 
entirely different algorithm could in fact be used to establish 
values for each of these fields. It will also be appreciated that 
one or two of the fields can be "hopped" rather than all three 
as illustrated. 

40 In accordance with another aspect of the invention, hard- 
ware or "MAC* addresses are hopped instead of or in 
addition to IP addresses and/or the discriminator field in 
order to improve security in a local area or broadcast-type 
network. To that end, node 1201 further maintains a transmit 

45 table 1210 using a transmit algorithm 1210X to generate 
source and destination hardware addresses that are inserted 
into frame headers (e.g., fields llOlAand UOIB in FIG. 11) 
that are synchronized to a corresponding receive table 1224 
at node 1202. Similarly, node 1202 maintains a different 

50 transmit table 1223 containing source and destination hard- 
ware addresses that is synchronized with a corresponding 
receive table 1211 at node 1201. In this manner, outgoing 
hardware frames appear to be originating from and going to 
completely random nodes on the network, even though each 

55 recipient can determine whether a given packet is intended 
for it or not. It will be appreciated that the hardware hopping 
feature can be implemented at a different level in the 
communications protocol than the IP hopping feature (e.g., 
in a card driver or in a hardware card itself to improve 

60 performance). 

FIG. 12B shows three different embodiments or modes 
that can be employed using the aforementioned principles. 
In a first mode referred to as "promiscuous" mode, a 
common hardware address (e.g., a fixed address for source 

65 and another for destination) or else a completely random 
hardware address is used by aU nodes on the network, such 
that a particular packet cannot be attributed to any one node. 
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Each aode must initially accept all packets containing the 
common (or random) hardware address and inspect the IP 
addresses or discriminator field to determine whether the 
packet is intended for that node. In this regard, either the IP 
addresses or the discriminator field or both can be varied in 5 
accordance with an algorithm as described above. As 
explained previously, this may increase each node's over- 
head since additional processing is involved to determine 
whether a given packet has valid source and destination 
hardware addresses. 10 

In a second mode referred to as "promiscuous per VPN" 
mode, a small set of fixed hardware addresses are used, with 
a fixed source/destination hardware address used for all 
nodes communicating over a virtual private network. For 
example, if there are six nodes on an Ethernet, and the 15 
network is to be split up into two private virtual networks 
such that nodes on one VPN can communicate with only the 
other two nodes on its own VPN, then two sets of hardware 
addresses could be used: one set for the first VPN and a 
second set for the second VPN. This would reduce the 20 
amount of overhead involved in checking for valid frames 
since only packets arriving from the designated VPN would 
need to be checked. IP addresses and one or more discrimi- 
nator fields could still be hopped as before for secure 
communication within the VPN, Of course, this solution 25 
compromises the anonymity of the VPNs (i.e., an outsider 
can easily tell what traffic belongs in which VPN, though he 
cannot correlate it to a specific machine/person). It also 
requires the use of a discriminator field to mitigate the 
vulnerability to certain types of DoS attacks. (For example, 30 
without the discriminator field, an attacker on the LAN 
could stream frames containing the MAC addresses being 
used by the VPN; rejecting those frames could lead to 
excessive processing overhead. The discriminator field 
would provide a low-overhead means of rejecting the false 35 
packets.) 

In a third mode referred to as "hardware happing" mode, 
hardware addresses are varied as illustrated in FIG. 12A, 
such that hardware source and destination addresses are 
changed constantly in order to provide non-attributable 40 
addressing. Variations on these embodiments are of course 
possible, and the invention is not intended to be limited in 
any respect by these illustrative examples. 
B. Extending the Address Space 

Address hopping provides security and privacy. However, 45 
the level of protection is limited by the number of addresses 
in the blocks being hopped. A hopblock denotes a field or 
fields modulated on a packet-wise basis for the purpose of 
providing a VPN. For instance, if two nodes communicate 
with IP address hopping using hopblocks of 4 addresses (2 50 
bits) each, there would be 16 possible address-pair combi- 
nations. A window of size 16 would result in most address 
pairs being accepted as valid most of the time. This limita- 
tion can be overcome by using a discriminator field in 
addition to or instead of the hopped address fields. The 55 
discriminator field would be hopped in exactly the same 
fashion as the address fields and it would be used to 
determine whether a packet should be processed by a 
receiver. 

Suppose that two clients, each using four-bit hopblocks, 60 
would hke the same level of protection afforded to clients 
communicating via IP hopping between two A blocks (24 
address bits eligible for hopping). A discriminator field of 20 
bits, used in conjunction with the 4 address bits eligible for 
hopping in the IP address field, provides this level of 65 
protection. A 24-bit discriminator field would provide a 
similar level of protection if the address fields were not 



hopped or ignored. Using a discriminator field offers the 
following advantages: (1) an arbitrarily high level of pro- 
tection can be provided, and (2) address hopping is unnec- 
essary to provide protection. This may be important in 
environments where address hopping would cause routing 
problems. 

C. Synchronization Techniques 

It is generally assumed that once a sending node and 
receiving node have exchanged algorithms and seeds (or 
similar information sufficient to generate quasi-random 
source and destination tables), subsequent communication 
between the two nodes will proceed smoothly. Realistically, 
however, two nodes may lose synchronization due to net- 
work delays or outages, or other problems. Consequently, it 
is desirable to provide means for re-establishing synchroni- 
zation between nodes in a network that have lost synchro- 
nization. 

One possible technique is to require that each node 
provide an acknowledgment upon successful receipt of each 
packet and, if no acknowledgment is received within a 
certain period of time, to re-send the unacknowledged 
packet. This approach, however, drives up overhead costs 
and may be prohibitive in high-throughput environments 
such as streaming video or audio, for example. 

A different approach is to employ an automatic synchro- 
nizing technique that will be referred to herein as "seff- 
synchronization." In this approach, synchronization infor- 
mation is embedded into each packet, thereby enabling the 
receiver to re-synchronize itself upon receipt of a single 
packet if it determines that is has lost synchronization with 
the sender. (If communications are already in progress, and 
the receiver determines that it is still in sync with the sender, 
then there is no need to re-synchronize.) A receiver could 
detect that it was out of synchronization by, for example, 
employing a "dead-man" timer that expires after a certain 
period of time, wherein the timer is reset with each valid 
packet. A time stamp could be hashed into the public sync 
field (see belOwJ'W^ffiS'luae packet-retry attacks. 

In one embodiment, a "sync field" is added to the header 
of each packet sent out by the sender. This sync field could 
appear in the clear or as part of an encrypted portion of the 
packet. Assuming that a sender and receiver have selected a 
random-number generator (RNG) and seed value, this com- 
bination of RNG and seed can be used to generate a 
random-number sequence (RNS). The RNS is then used to 
generate a sequence of source/destination IP pairs (and, if 
desired, discriminator fields and hardware source and des- 
tination addresses), as described above. It is not necessary, 
however, to generate the entire sequence (or the first N-1 
values) in order to generate the Nth random number in the 
sequence; if the sequence index N is known, the random 
value corresponding to that index can be directly generated 
(see below). Different RNGs (and seeds) with different 
fundamental periods could be used to generate the source 
and destination IP sequences, but the basic concepts would 
still apply. For the sake of simplicity, the following discus- 
sion will assume that IP source and destination address pairs 
(only) are hopped using a single RNG sequencing mecha- 
nism. 

In accordance with a "self -synchronization" feature, a 
sync field in each pa cket header pr ovides an index (i.e.. a^ 

[ce number") [ into the RNS that is being used to 
generate IP pairsT Plugging this index into the RNG that is 
being used to generate the RNS yields a specific random 
number value, which in turn yields a specific IP pair. That is, 
an IP pair can be generated directly frojn knowledge of the 
RNG, seed, and index number; it is not necessary, in this 
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scheme, to generate the entire sequence of random numbers 
that precede the sequence value associated with the index 
number provided. 

Since the communicants have presumably previously 
exchanged RNGs and seeds, the only new information that 
miK^I |v> pmvid^ in order to generate a n IP pair is the 
sequence num bgr. | If this number is provided by the sender 
~m me packet'Teader, then the receiver need only plug this 
number into the RNG in order to generate an IP pair — and 



sender and a second ISP 1303 is the receiver. (Other alter- 
natives are possible from FIG. 13.) A transmitted packet 
comprises a public or "outer" header 1305 that is not 
encrypted, and a private or "inner" header 1306 that is 
encrypted using for example a link key. Outer header 1305 
includes a public sync portion while inner header 1306 
contains the private sync portion. A receiving node decrypts 
the inner header using a decryption function 1307 in order 
to extract the private sync portion. This step is necessary 



thus verify that the IP pair appearing in the header of the lO o°ly if the lifetime of the currently buffered private sync has 



packcfisva l iSl lElhis scheme, if the sender and receiver lose 
^ fl "synchronization, the receiver can immediately 
re-sYnchro nize upon receipt of a single packet by' simply 
[com parin fl the IP pair in the packet header to the IP pair 
^generateJ irom the index number . Thus, synchronized com- 
munications can be resumed upon receipt of a single packet, 
making this scheme ideal for multicast communications. 
Taken to the extreme, it could obviate the need for synchro- 
nization tables entirely; that is, the sender and receiver could 



expired. (If the currently-buffered private sync is still valid, 
then it is simply extracted from memory and "added" (which 
could be an inverse hash) to the public sync, as shown in step 
1308.) The public and decrypted private sync portions are 
J 5 combined in function 1308 in order to generate the com- 
bined sync 1309. The combined sync (1309) is then fed into 
the RNG (1310) and compared to the IP address pair (1311) 
to validate or reject the packet. 

An important consideration in this architecture is the 



k simply rely on the index number in the sync field to validate 20 concept of "future" and "past" where the public syncvahies 



the IP pair on each packet, and thereby eliminate the tables 
entirely. 

The aforementioned scheme may have some inherent 
security issues associated with it — namely, the placement of 
the sync field. If the field is placed in the outer header, then 25 
an interloper could observe the values of the field and their 
relationship to the IP stream. This could potentially com- 
promise the algorithm that is being used to generate the 
IP-address sequence, which would compromise the security 



are concerned. TTiough the sync values, themselve^^hould 
be random to prevent spoofing attacks, it may be important 
that the receiver be able lo quf^jTttientify a sync value that 
has already been sent — even if the packet containing that 
sync value was never actually rec eived by the receiv er. One 
soluti oEi is^to hash a time stamp orl<ipniif^p'^ftjiii^'Tpber|into the 
^^ mibjig-sync p ort ion^ which could be iguickrv^^ext r acteiS^ 
che^cd^^ d_jiscar j&^ validating the public sync 

^ R gtjio njtsglf 



of the communications. If, however, the value is placed in 30,--Jii embodiment, packets can be checked b ^ompa r^ 

[ ing\the source/destination IP pair generated by thesync liela 



the inner header, then the sender must decrypt the inner 
header before it can extract the sync value and validate the 
IP pair; this opens up the receiver to certain types of 
denial-of-service (DoS) attacks, such as packet replay. That 
is, if the receiver must decrypt a packet before it can validate 35 
the IP pair, then it could potentially be forced to expend a 
significant amount of processing on decryption if an attacker 
simply retransmits previously valid packets. Other attack 
methodologies are possible in this scenario. 

A possible compromise between algorithm security and 40 
processing speed is to split up the sync value between an 
inner (encrypted) and outer (unencrypted) header. That is, if 
the sync value is sufficiently long, it could potentially be 
split into a rapidly-changing part that can be viewed in the 



"mth the pair appearing in the-packet header. If (1) the^^ 
match2j(2) the time stamp is valid, and (3) the dead-man 
Hmer has ^e xpi TSaT^ffienT re^ynchronizatibn occurs; 
otherwise, the packet is rejected. If enough processing 
power is availaBleftflfSeS-m^Ttimer and synchronization 
tables can be avoided altogether, and the receiver would 
simply resynchronize (e.g., validate) on every packet. 

The foregoing scheme may require large-integer (e.g., 
160-bit) math, which may affect its implementation. Without 
such large -integer registers, processing throughput would be 
affected, thus potentially affecting security from a denial- 
of-service standpoint. Nevertheless, as large-integer math 
processing features become more prevalent, the costs of 



clear, and a fixed (or very slowly changing) part that must be 45 implementing such a feature will be reduced. 



protected. The part that can be viewed in the clear will be 
called the "public sync" portion and the part that must be 
protected will be called the "private sync" portion. 

Both the public sync and private sync portions are needed 
to generate the complete sync value. The private portion, 
however, can be selected such that it is fixed or will change 
only occasionally. Thus, the private sync value can be stored 
by the recipient, thereby obviating the need to decrypt the 
header in order to retrieve it. If the sender and receiver have 
previously agreed upon the frequency with which the private 55 
part of the sync will change, then the receiver can selectively 
decrypt a single header in order to extract the new private 
sync if the communications gap that has led to lost synchro- 
nization has exceeded the lifetime of the previous private 



D. Other Synchronization Schemes 

As explained above, if W or more consecutive packets are 
lost between a transmitter and receiver in a VPN (where W 
is the window size), the receiver's window will not have 
50 been updated and the transmitter will be transmitting packets 
not in the receiver's window. The sender and receiver will 
not recover synchronization until perhaps the random pairs 
in the window are repeated by chance. Therefore, there is a 
need to keep a transmitter and receiver in synchronization 
whenever possible and to re-establish synchronization 
whenever it is lost. 

A "checkpoint" scheme can be used to regain synchroni- 
zation between a sender and a receiver that have fallen out 
of synchronization. In this scheme, a checkpoint message 



sync. This should not represent a burdensome amount of 60 comprising a random IP address pair is used for communi- 



decryption, and thus should not open up the receiver to 
denial-of-service attack simply based on the need to occa- 
sionally decrypt a single header. 

One implementation of this is to use a hashing function 
with a one-to-one mapping to generate the private and public 65 
sync portions from the sync value. This implementation is 
shown in FIG. 13, where (for example) a first ISP 1302 is the 



eating synchronization information. In one embodiment, 
two messages are used to communicate synchronization 
information between a sender and a recipient: 

1, SYNC_REQ is a message used by the sender to 
indicate that it wants to synchronize; and 

2. SYNC_ACK is a message used by the receiver to 
inform the transmitter that it has been synchronized. 
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According to one variation of this approach, both th e tra^] S|- case, it is desirable to move the window ahead without 

mitt er and receiver maintain three checkpoints (s ee FIG. 14): having to step through the intervening random numbers 

T. In the transmitter, ckpt o ("checkpoint old") is the IP sequentially. (This feature is also desirable for the auto-sync 

pair that was used to re-send the last SYNC_REQ approach discussed above). 

packet to the receiver. In the receiver, ckpt_o 5 E. Random Number Generator with a Jump-Ahead Capa- 

(" checkpoint old") is the IP pair that receives repeated bility 

SYNC_REQ packets from the transmitter. An attractive method for generating randomly hopped 

2. In the transmitter, ckpt_n ("checkpoint new"') is the IP addresses is to use identical random number generators in 
pair that will be used to send the next SYNC_REQ the transmitter and receiver and advance them as packets are 
packet to the receiver. In the receiver, ckpt„n 10 transmitted and received. There are many random number 
("checkpoint new"*) is the IP pair that receives a new generation algorithms that could be used. Each one has 
SYNC_REQ packet from the transmitter and which strengths and weaknesses for address hopping applications, 
causes the receiver's window to be re -aligned, ckpt_o Linear congruential random nimiber generators (LCRs) 
set to ckpt„n, a new ckpt_n to be generated and a new are fast, simple and well characterized random number 
ckpt_r to be generated. 15 generators that can be made to jump ahead n steps efi&ciently. 

3. In the transmitter, ckpt__r is the IP pair that will be used An LCR generates random numbers X^, Xj, X3 . . . X^. 
to send the next SYNC_ACK packet to the receiver. In starting with seed Xq using a recurrence 

the receiver, ckpt_r is the IP pair that receives a new 

SYNC__ACK packet from the transmitter and which Xr(aXt.^+b)mod c, (i) 

causes a new ckpt_n to be generated. Since SYNC 20 . u j j c 1 t /-.n * *l 

ACK is transmitted from the receiver ISP to the send^ J^'^ ^ '^''^^ » P^""^"^^' LCR. Another expression 

ISP, the transmitter ckpt_r refers to the ckpt_r of the " 

rec eiver and the receiver ckpt_r refers to the ckpt_r of A^^((a'(;fo+6)-6)/(a-i))mod c (2) 
the jS'ansmitterK see FIG. 14). 

When a transmitter initia tes synchronization, the IP pair it 25 enables the jump-ahead capability. The factor a' can grow 

will use to transmit the next data packet is set to a prede- very large even for modest i if left unfettered. Therefore 

termined value and when a receiver first receives a SYNC some special properties of the modulo operation can be used 

REQ, the receiver window is updated to be centered on the to control the size and processing time required to compute 

transmitter's next IP pair. This is the primary mechanism for (2). (2) can be rewritten as: 

checkpoint synchronization. 30 

Synchronization can be initiated by a packet counter (e.g., Xr{(^{x^a-i)+b)-b)i{a-i)mod c. (3) 

after every N packets transmitted, initiate a synchronization) ^ shown that- 
or by a timer (every S seconds, initiate a synchronization) or 

a combination of both. See FIG. 15. From the transmitter's {a'^tj[a-i)+byb)/{a-i)mod c-((a' mod{{a-i)c)(XJia-i)+b)-by 

perspective, this technique operates as follows: (1) Each 35 (a-i))mod c (4). 

transmitter periodically transmits a "sync request" message ^ 1 x . 1 / . ^ 11 

to the receiver to make sure that it is in sync. (2) If the (Xo(a-l)+b) can be stored as (X^^^^^^ 

receiver is stiU in sync, it sends back a "sync ack" message. ^ ^"f ^^°^P^^^. ^ mod((a-l)c) (this requires 0(log(i)) steps). 

(If this works, no further action is necessary). (3) If no "sync ^^^^^ implementation of this algorithm would jump 

ack" has been received within a period of time, the trans- 40 ^ ^""^ ^^t^ncc, n, between synchronizations; this is tanta- 

mitter retransmits the sync request again. If the transmitter synchromzing every n packets The wmdow would 

reaches the next checkpoint without receiving a "sync ack" "'"^^"^ P^f ^^"^ ^^^^ P^^^^^^. 

response, then synchronization is broken, and the transmitter ^^^^ J checkpomt, as Xo 

should stop transmitting. The transmitter wUl continue to ° ^ ^' ^ ^^""'^ ^ mod((a-l)c) once per LCR 

send sync_reqs until it receives a sync_ack, at which point 45 

transmission is reestablished. _ mod((«-i)c)C^,na-i)+t)-ma-i))mod c, (5) 

From the receiver s perspective, the scheme operates as 
follows: (1) when it receives a "sync request" request from to generate the random number for the j+1'* synch roniza- 
the transmitter, it advances its window to the next check- tion. Using this construction, a node could jump ahead an 
point position (even skipping pairs if necessary), and sends 50 arbitrary (but fixed) distance between synchronizations in a 
a "sync ack" message to the transmitter. If sync was never constant amount of time (independent of n). 
lost, then the "jump ahead" really just advances to the next Pseudo-random number generators, in general, and LCRs, 
available pair of addresses in the table (i.e., normal in particular, will eventually repeat their cycles. This rep- 
advancement), etition may present vulnerability in the IP hopping scheme. 

If an interloper intercepts the "sync request" messages 55 An adversary would simply have to wait for a repeat to 

and tries to interfere with communication by sending new predict future sequences. One way of coping with this 

ones, it will be ignored if the synchronization has been vulnerability is to create a random number generator with a 

estabUshed or it it will actually help to re-establish synchro- known long cycle. A random sequence can be replaced by a 

nization. new random number generator before it repeats, LCRs can 

A window is realigned whenever a re-synchronization 60 be constmcted with known long cycles. This is not currently 

occurs. This realignment entails updating the receiver's true of many random number generators, 

window to straddle the address pairs used by the packet Random number generators can be cryptographically 

transmitted immediately after the transmission of the insecure. An adversary can derive the RNG parameters by 

SYNC_REQ packet. Normally, the transmitter and receiver examining the output or part of the output. This is true of 

are in synchronization with one another. However, when 65 LCGs. This vulnerability can be mitigated by incorporating 

network events occur, the receiver's window may have to be an encryptor, designed to scramble the output as part of the 

advanced by many steps during resynchronization. In this random number generator. The random number generator 
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prevents an adversary from mounting an attack — e.g., a the packet is hostile, and reject any hostile packets or 
known plaintext attack — against the encryptor. determine which active IP pair the packet header matches. 

R Random Number Generator Example The problem is a classical associative memory problem. A 

Consider a RNG where a=31,b=4 and c=15. For this case variety of techniques have been developed to solve this 
equation (1) becomes: 5 problem (hashing, B -trees etc). Each of these approaches has 

its strengths and weaknesses. For instance, hash tables can 
Xi=(3iXi.^+4)mod 15. (6) be made to operate quite fast in a statistical sense, but can 

occasionally degenerate into a much slower algorithm. This 
If one sets Xo=l, equation (6) will produce the sequence slowness can persist for a period of time. Since there is a 
1, 5, 9, 13, 2, 6, 10, 14, 3, 7, 11, 0, 4, 8, 12. This sequence need to discard hostile packets quickly at all times, hashing 
will repeat indefinitely. For a jump ahead of 3 numbers in would be unacceptable, 
this sequence a"=31^=29791, c*(a-l)=. 15*30=450 and a" H. Presence Vector Algorithm 

mod((a-l)c)=31^ mod(15*30)=29791 mod(450)=91. Equa- A presence vector is a bit vector of length 2" that can be 
tion (5) becomes: indexed by n-bit numbers (each ranging from 0 to 2"-l), 

One can indicate the presence of k n-bit numbers (not 
(C9l(;ir,30+4)-4)/30)mod 15 (7). 15 necessarily unique), by setting the bits in the presence vector 

indexed by each number to 1. Otherwise, the bits in the 
Table 1 shows the jump ahead calculations from (7) . The presence vector are 0. An n-bit number, x, is one of the k 
calculations start at 5 and jump ahead 3. numbers if and only if the x^ bit of the presence vector is 1. 

A fast packet filter can be implemented by indexing the 
TABLE 1 20 presence vector and looking for a 1, which will be referred 

to as the "test." 

For example, suppose one wanted to represent the number 
135 using a presence vector. The 135 bit of the vector 
would be set. Consequently, one could very quickly deter- 
25 mine whether an address of 135 was valid by checking only 
one bit: the 135^ bit. The presence vectors could be created 
in advance corresponding to the table entries for the IP 
addresses. In effect, the incoming addresses can be used as 
G Fast Packet Filter indices into a long vector, making comparisons very fast. As 

* . J , , . . -ji J . • L 30 each RNG generates a new address, the presence vector is 

Address hoppmg VPNs must rapidly determme whether a j . j . a * .i. • r a .t. • j 

, , . i j 1. J J • r .t. updated to reflect the mformation. As the wmdow moves, 

packet has a valid header and thus requires further . • j * j . * jj . 

. . •vji_j/i_*M the presence vector is updated to zero out addresses that are 

processing, or has an invahd header (a hostile packet) and valid 

should be immediately rejected. Such rapid determinations • "j cc l ' «• • c.i. . ^ j .t. 

.„ . ^ 1 • »Tn.- u-1* There is a trade-off between efiSciency of the test and the 

wiU be referred to as fast packet fillermg. This capabihty , r * ^ f * • *u 

. . xmvrr i l j l . 35 amount of memory reqmred lor stonug the prcseucc vcctor 

protects the VPN from attacks by an adversary who streams /\t7-. -r , *u^ou-*fu 

[. 1 * * *u • ; u- u * r J • *i- (s). For mstance, if one were to use the 48 bits of hopping 

hostile packets at the receiver at a high rate of speed in the - a *u * u * u 

. / 11J addresses as an mdex, the presence vector would have to be 

hope of samrating the receiver s processor (a so<alled --^ . , ^, i *u- • * i f *• i 

• ^ c • » 1 \ * 1 * • • • 35 terabytes. Clearly, this IS too large for practical purposes, 

"denial of service attack). Fast packet filtermg IS an impor- ^ * j *u u-* u -j j - * i n c u 

tant feature for implementing VPNs on shared media such as 

Ethernet 
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Instead, the 48 bits can be divided into several smaller fields, 
40 For instance, one could subdivide the 48 bits into four 12-bit 



. . ,v , 11 ' , . xrnxT L fields (see FIG. 16). This reduces the storage requirement to 

Assuming that aU participants m a VPN share an unas- ^^ao * . c n u • * 

j«*"t.i 1 r jj u i -. • . 2048 bytes at the expense of occasionaUy havmg to process 

signed A block of addresses, one possibility is to use an ,.i i.T rc^-.jr i 

* ^ ^ •> a hostile packet. In effect, instead or one long presence 



experimental "A" block that will never be assigned to any 



^. , ,j V - *u u J J- vector, the decomposed address portions must match aU four 

machine that is not address hopping on the shared medium. , . * * u ^ ^ *u • 

u* f jj * u u J 45 shorter presence vectors before further processing is 

A blocks have a 24 bits of address that can be hopped as „ , .uc* ♦f^u a a *• j w 

A* .u o U-* - «r^"ui 1 I u ui 1 allowed. (If the first part of the address portion doesn t 

opposed to the 8 bits in C blocks. In this case a hopblock * i_ .t. ^ . * .i_ • j . i_ i .t. 

•iVu *i. « A " ui 1 Tn, P*t. • * 1 « A*» ui 1 match the first presence vector, there is no need to check the 

will be the "A block. The use of the experimental "A block • • *u / \ 

, . . ^ remaining three presence vectors), 

is a likely option on an Ethernet because: . ♦ n u i • *u x/i u-. f j i 

^ ^ A presence vector will have a 1 in the y bit if and only 

1. The addresses have no validity outside of the Ethernet 50 if one or more addresses with a corresponding field of y are 
and will not be routed out to a valid outside destination ^^^^^^ ^ address is active only if each presence vector 
by a gateway. indexed by the appropriate sub-field of the address is 1. 

2. There are 2^'* (-16 miUion) addresses that can be Consider a window of 32 active addresses and 3 check- 
hopped within each "A" block. This yields >280 trillion points. A hostile packet will be rejected by the indexing of 
possible address pairs making it very unlikely that an 55 one presence vector more than 99% of the time. A hostile 
adversary would guess a valid address. It also provides packet will be rejected by the indexing of all 4 presence 
acceptably low probability of collision between sepa- vectors more than 99.9999995% of the time. On average, 
rate VPNs (all VPNs on a shared medium indepen- hostile packets wiU be rejected in less than 1.02 presence 
dently generate random address pairs from the same vector index operations. 

"A" block). 60 The small percentage of hostile packets that pass the fast 

3. The packets will not be received by someone on the packet filter wiU be rejected when matching pairs are not 
Ethernet who is not on a VPN (unless the machine is in found in the active window or are active checkpoints, 
promiscuous mode) minimizing impact on non-VPN Hostile packets that serendipitously match a header will be 
computers, rejected when the VPN software attempts to decrypt the 

The Ethernet example will be used to describe one 65 header. However, these cases will be extremely rare. There 

implementation of fast packet filtering. The ideal algorithm are many other ways this method can be configured to 

would quickly examine a packet header, determine whether arbitrate the space/speed tradeoflfe. 
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I. Further Syachronization Enbaacemeals between ISPs is labeled in FIG. 20 to indicate a specific 

A slightly modified form of the synchronization tech- physical transmission path (e.g., AD is a physical path that 

niques described above can be employed. The basic prin- links ISP A (element 2005) to ISP D (element 2008)). 

ciples of the previously described checkpoint synchroniza- Packets arriving at each edge router are selectively trans- 
tion scheme remain unchanged. The actions resulting firom 5 mitted to one of the ISPs to which the router is attached on 

the reception of the checkpoints are, however, slighUy the basis of a randomly or quasi-randomly selected basis, 

different. In this variation, the receiver will maintain ^s shown in FIG. 21, computer 2001 or edge router 2003 

between OoO ("Out of OrdeO and JxWINTOOW^^^^ incorporates a plurality of link transmission tables 2100 that 

wrvn^w' c,^^'>if ^!-r.°°°7 w.^^^«rc.l-n identify, for each potential traiismission path thmugh the 

WINDOW SIZE^l). OoO and WINDOW^SIZE are ^^^^J^ ^^^^ „f ,p ^^^^^^ be uLl to 

engmeerable parameter, where OoO is the mimmum num- ^^^^^^ ^.^^ ^ ^ ^^^^^^ 2101 contains a 

ber of address needed to accommodate lost packets due to „f ,p source/destination pairs that are randomly or 

^r^n^^r^^ 'c^^^'"^"? °' T . ' quasi-randomly generated. When a packet is to be transmit- 

n^'^ ■ transmitted jOOl to second computer 2002, one 

before a SYNC_REQ is issued. FIG. 17 depicts a storage „f j^^^ j^y^^ ^ ^^^^^^ quasi-randomly) selected, 

array for a receiver s active addr^es and the next valid source/destination address pair from that 

The receiver starts with the first 2xWIND0W_SI^ ^^le is used to transmit the packet through the network. If 

addresses loaded and active (ready to receive data). As ^ ^^^^^^j ^j^^j^^ j ^^^^^ 

packets are received, the corresponding entnes are marked destination IP address pair (which is pre-determined to 

as used and are no longer ehgible to receive packets. TTie ^^^^ between ISP A (element 2005) and ISP B (element 

transmitter mamtams a packet counter, imtially set to 0, jOOS)) is used to transmit the packet. If one of the trans- 

contaimng the number of data packets transmuted smce the ^^^^ ^^ ^^^^^^ degraded or inoperative, that Unk 

o^r^°"*l.^"u'°"f' °° °^ ^ table can be set to a "down" condition as shown in table 

SYNC_ACK has been re«ived When the transmitter jlOS, thus preventing addresses from being selected from 
packet couruer equals WINDOW_SIZE, die transmitter ^ that table. Other transmission paths would be unaffected by 

generates a SYNC_REQ and does its initial transmission. jj^^^ bfoken link 
When the receiver receives a SYNC_REQ corresponding to 

its current CKPT_N, it generates the next WINDOW_ 3. CONTINUAnON-IN-PART IMPROVEMENTS 

SIZE addresses and starts loading them in order starting at j^^^ j^jj^^ ^^^^^^^ ^^-^^^ improvements and fea- 
the first location after the last active address wrapping 3^ j^^^s that can be applied to the embodiments described 

around to the beginning of the array after the end of the array ^^ove. Tlie improvements include: (1) a load balancer that 

has been reached Tte receiver s array might look hke FIG. jistrfbutes packets across different transmission paths 

18 when a SYNCJiEQ has been received, n this case a according to transmission path quality; (2) a DNS proxy 

couple of packets have been either lost or will be received ^^^^ transparendy creates a virhial private network in 
r^^ "^'^^u u S^S-'^EQ 35 response to a domain name inquiry; (3) a large-to-smaU Unk 

no. 19 shows the receivers array after the new addresses bandwidth management feature that prevents denialK)f- 

have been generated. If the transmitter does not receive a • . chokeooints- (4^ a traffic limiter 

SYNC ACK, it will re-issue the SYNC REQ at regular i f ■ v . k J •.• .u 

— . . . ;r;,^,J^r » , that regulates incommg packets by hmitmg the rate at which 

mtervals. When the transmitter receives a SYNC ACK the ^ transmitter can be synchronized with a receiver; and (5) a 

packet counter is decremented by Wir«^^^ If the ,j ^ synchronizer that aUows a large number of nodes 

packet counter reaches 2xWINDOW_SIZE--OoO then the communicate with a central node by partitioning the 

^^T^^Z"^^ T'^u^ data packete until the appropriate communication function between two separate entities. Each 

SYNC_ACK IS finally received. The transmitter then is discussed separately below, 

resumes sending data packets. Future behavior is essentially ^ j^^^ Balancer 

a repetition of this initial cycle. TTie advantages of this Various embodiments described above include a system in 

approac are. which a transmitting node and a receiving node are coupled 

1. There is no need for an efficient jump ahead in the through a plurality of transmission paths, and wherein 
random number generator, successive packets are distributed quasi-randomly over the 

2. No packet is ever transmitted that does not have a pluraUty of paths. See, for example, FIGS, 20 and 21 and 
corresponding entry in the receiver side 50 accompanying description. The improvement extends this 

3. No timer based re -synchronization is necessary. This is basic concept to encompass distributing packets across 
a consequence of 2. different paths in such a manner that the loads on the paths 

4. The receiver will always have the ability to accept data are generally balanced according to transmission link qual- 
messages transmitted within OoO messages of the most ity. 

recently transmitted message. 55 In one embodiment, a system includes a transmitting node 

J. Distributed Transmission Path Variant and a receiving node that are linked via a plurality of 

Another embodiment incorporating various inventive transmission paths having potentially varying transmission 

principles is shown in FIG. 20. In this embodiment, a quality. Successive packets are transmitted over the paths 

message transmission system includes a first computer 2001 based on a weight value distribution function for each path, 
in communication with a second computer 2002 through a 60 The rate that packets will be transmitted over a given path 

network 2011 of intermediary computers. In one variant of can be different for each path. The relative "health" of each 

this embodiment, the network includes two edge routers transmission path is monitored in order to identify paths that 

2003 and 2004 each of which is linked to a plurality of have become degraded. In one embodiment, the health of 

Internet Service Providers (ISPs) 2005 through 2010. Each each path is monitored in t he transmitter b^ fo mpa^m'^ the 
ISPis coupled to a plurality of other ISPs in an arrangement 65 |^'mhf^ p^rKfl^ transmTtlecl to the number ot packe t 

as shown in FIG. 20, which is a representative configuration ac knowledgements rece ived. Each transmission path may 

only and is not intended to be limiting. Each connection comprise a physically separate path (e.g., via dial-up phone 
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line, computer network, router, bridge, or the like), or may In step 2203, the link quality is compared to a given 

comprise logically separate paths contained within a broad- threshold (e.g., 50%, or any arbitrary number). If the quality 

band communication medium (e.g., separate channels in an falls below the threshold, then in step 2207 a check is made 

FDM, TDM, CDMA, or other type of modulated or to determine whether the weight is above a minimum level 

unmodulated transmission link). 5 (e.g., 1%), if not, then in step 2209 the weight is set to the 

When the transmission quaUty of a path falls below a minimum level and processing resumes at step 2201. If the 

predetermined threshold and there are other paths that can weight is above the minimum level, then in step 2208 the 

transmit packets the transmitter chaiiges the weight value ^^- ^^ ^ graduaUy decreased for the path, then in step 2206 

used for that path making U less hkely that a given packet ^^-^^ remaining paths are adjusted accordingly 

wiU be transmitted over that path. The weight compensate (e.g., they are increased), 

be set no lower than a mmimum value that keeps nominal . * 

traffic on the path. The weights of the other available paths '^"^ ^^^^ l l'^^'t path was greater than or 
are altered to compensate for the change in the affected path. ^^^^^ ^° threshold then m step 2204 a check is made to 
When the quality of a path degrades to where the transmitter determme whether the weight is less than a steady-state 
is turned off by the synchronization function (i.e., no packets ^^^^ P^^*^* ^' ^ step 2205 the weight is 
are arriving at the destination), the weight is set to zero. If increased toward the steady-state value, and in step 2206 the 
all transmitters are turned off, no packets are sent. weights for the remaining paths are adjusted accordingly to 
Conventional TCP/IP protocols include a "throttling" compensate (e.g., they are decreased). If in step 2204 the 
feature that reduces the transmission rate of packets when it weight is not less than the steady-state value, then process- 
is determined that delays or errors are occurring in trans- ing resumes at step 2201 without adjusting the weights, 
mission. In this respect, timers are sometimes used to 20 The weights can be adjusted incrementally according to 
determine whether packets have been received. These con- various functions, preferably by changing the value gradu- 
ventional techniques for limiting transmission of packets, ally. In one embodiment, a linearly decreasing function is 
however, do not involve multiple transmission paths used to adjust the weights; according to another 
between two nodes wherein transmission across a particular embodiment, an exponential decay function is used. Gradu- 
path relative to the others is changed based on link quality. 25 ally changing the weights helps to damp oscillators that 

According to certain embodiments, in order to damp might otherwise occur if the probabilities were abruptly, 

oscillations that might otherwise occur if weight distribu- Although not explicitly shown in FIG. 22 A the process 

tions are changed drastically (e.g., according to a step can be performed only periodically (e.g., according to a time 

function), a linear or an exponential decay formula can be schedule), or it can be continuously run, such as in a 

applied to gradually decrease the weight value over time that 30 background mode of operation. In one embodiment, the 

a degrading path will be used. Similarly, if the health of a combined weights of all potential paths should add up to 

degraded path improves, the weight value for that path is unity(e.g., when the weighting for one path is decreased, the 

gradually increased. . corresponding weights that the other paths will be selected 
/ Transmission link health can be evaluated bvf comparingj will increase), 

the number of packets that are acknowledged within the 35 Adjustments to weight values for other paths can be 

' ^ transmission window (see embodiments discussed above) to prorated. For example, a decrease of 10% in weight value for 

the number of packets transmitted within that window and one path could result in an evenly distributed increase in the 

by the state of the transmitter (i.e., on or off). In other words, weights for the remaining paths. Alternatively, weightings 

rather than accumulating general transmission statistics over could be adjusted according to a weighted formula as 

time for a path, one specific implementation uses the "win- 40 desired (e.g., favoring healthy paths over less healthy paths), 

dowing" concepts described above to evaluate transmission In yet another variation, the difference in weight value can 

path health. be amortized over the remaining links in a manner that is 

The same scheme can be used to shift virtual circuit paths proportional to their trafiSc weighting, 

from an "unhealthy" path to a "healthy*' one, and to select FIG. 22B shows steps that can be executed to shut down 

a path for a new virtual circuit. 45 transmission links where a transmitter turns off. In step 

FIG. 22 A shows a flowchart for adjusting weight values 2210, a transmitter shut-down event occurs. In step 22U, a 

associated with a plurality of transmission links. It is test is made to determine whether at least one transmitter is 

assumed that software executing in one or more computer still turned on. If not, then in step 2215 all packets are 

nodes executes the steps shown in FIG. 22 A. It is also dropped until a transmitter turns on. If in step 2211 at least 

assumed that the software can be stored on a computer- 50 one transmitter is turned on, then in step 2212 the weight for 

readable medium such as a magnetic or optical disk for the path is set to zero, and the weights for the remaining 

execution by a computer. paths are adjusted accordingly. 

Beginning in step 2201, the transmission quality of a FIG. 23 shows a computer node 2301 employing various 
given transmission path is measured. As described above, principles of the above -described embodiments. It is 
this measurement can be based on a comparison between the 55 assumed that two computer nodes of the type shown in FIG. 
number of packets transmitted over a particular link to the 23 communicate over a plurality of separate physical trans- 
number of packet acknowledgements received over the link mission paths. As shown in FIG. 23, four transmission paths 
(e.g., per unit time, or in abso lute tenp alAlternatively, the XI through X4 are defined for communicating between the 
quality can be evaluated bv [ comparing I the number of two nodes. Each node includes a packet transmitter 2302 
packets that are acknowledged within the transmission win- 60 that operates in accordance with a transmit table 2308 as 
dow to the number of packets that were transmitted within described above. (The packet transmitter could also operate 
that window. In yet another variation, the number of missed without using the IP-hopping features described above, but 
synchronization messages can be used to indicate link the following description assumes that some form of hbp- 
quality. Many other variations are of course possible. ping is employed in conjunction with the path selection 
In step 2202, a check is made to determine whether more 65 mechanism.). The computer node also includes a packet 
than one transmitter (e.g., transmission path) is turned on. If receiver 2303 that operates in accordance with a receive 
not, the process is terminated and resumes at step 2201. table 2309, including a moving window W that moves as 
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valid packets are received. Invalid packets having source 
and destination addresses that do not fall within window W 
are rejected. 

As each packet is readied for transmission, source and 
destination IP addresses (or other discriminator values) are 5 
selected from transmit table 2308 according to any of the 
various algorithms described above, and packets containing 
these source/destination address pairs, which correspond to 
the node to which the four transmission paths are linked, are 
generated to a transmission path switch 2307. Switch 2307, 
which can comprise a software function, selects from one of 
the available transmission paths according to a weight 
distribution table 2306. For example, if the weight for path 
XI is 0.2, then every fifth packet will be transmitted on path 
XI. A similar regime holds true for the other paths as shown. 
Initially, each link's weight value can be set such that it is 
proportional to its bandwidth, which will be referred to as its 
"steady-state" value. 

Packet receiver 2303 generates an output to a Hnk quality 
measurement function 2304 that operates as described above 
to determine the quality of each transmission path. (The 20 
input to packet receiver 2303 for receiving incoming packets 
is omitted for clarity). Link quality measurement ftinction 
2304 compares the link quality to a threshold for each 
transmission link and, if necessary, generates an output to 
weight adjustment function 2305. If a weight adjustment is 25 
required, then the weights in table 2306 are adjusted 
accordingly, preferably according to a gradual (e.g., linearly 
or exponentially declining) function. In one embodiment, 
the weight values for all available paths are initially set to 
the same value, and only when paths degrade in quality are 30 
the weights changed to reflect differences, 

link quality measurement function 2304 can be made to 
operate as part of a synchronizer function as described 
above. That is, if resynchronization occurs and the receiver 
detects that synchronization has been lost (e.g., resulting in 35 
the synchronization window W being advanced out of 
sequence), that fact can be used to drive link quality mea- 
surement function 2304. According to one embodiment, 
load balancing is performed using information garnered 
during the normal synchronization, augmented slightly to 40 
communicate link health from the receiver to the transmitter. 
The receiver maintains a count, MESS_R(W), of the mes- 
sages received in synchronization window W. When it 
receives a synchronization request (SYNC_REQ) corre- 
sponding to the end of window W, the receiver includes 45 
counter MESS_R in the resulting synchronization acknowl- 
edgement rSYNC^AC K) sent ba ck to the transmitter. This 
allows the transmitter t dcompareV nessages sent to messages 
received in order to asses tne nealth of the link. 

If synchronization is completely lost, weight adjustment 50 
function 2305 decreases the weight value on the affected 
path to zero. When synchronization is regained, the weight 
value for the affected path is gradually increased to its 
original value. Alternatively, link quality can be measured 
by evaluating the length of time required for the receiver to 55 
acknowledge a synchronization request. In one embodiment, 
separate transmit and receive tables are used for each 
transmission path. 

When the transmitter receives a SYNC_ACK, the 
MESS_R is compared with the number of messages trans- 60 
mitted in a window (MESS_T). When the transmitter 
receives a SYNC_ACK, the trafiSc probabilities will be 
examined and adjusted if necessary. MESS_R is compared 
with the number of messages transmitted in a window 
(MESS_T). There are two possibilities: 65 

1. If MESS_R is less than a threshold value, THRESH, 
then the link will be deemed to be unhealthy. If the 



Bl 

36 

transmitter was turned off, the transmitter is turned on 
and the weight P for that link will be set to a minimum 
value MIN. This will keep a trickle of traffic on the link 
for monitoring purposes until it recovers. If the trans- 
mitter was turned on, the weight P for that link will be 
set to: 

P=axMIN+(l-a)xP (1) 

Equation 1 will exponentially damp the traffic weight value 
to MIN during sustained periods of degraded service. 
2. If MESS_R for a link is greater than or equal to 
THRESH, the link wiU be deemed healthy. If the 
weight P for that link is greater than or equal to the 
steady state value S for that link, then P is left unaltered. 
If the weight P for that link is less than THRESH then 
P will be set to: 

f'=px5+(l-P)xP (2) 

where p is a parameter such that 0<=p<=l that determines 
the damping rate of P. 

Equation 2 will increase the traffic weight to S during 
STistained periods of acceptable service in a damped expo- 
nential fashion. 

A detailed example will now be provided with reference 
to FIG. 24. As shown in FIG, 24, a first computer 2401 
communicates with a second computer 2402 through two 
routers 2403 and 2404. Each router is coupled to the other 
router through three transmission links. As described above, 
these may be physically diverse links or logical links 
(including virtual private networks). 

Suppose that a first link LI can sustain a transmission 
bandwidth of 100 Mb/s and has a window size of 32; link L2 
can sustain 75 Mb/s and has a window size of 24; and link 
L3 can sustain 25 Mb/s and has a window size of 8. The 
combined links can thus sustain 200 Mb/s. The steady state 
traffic weights are 0.5 for hnk LI; 0.375 for link L2, and 
0.125 for Unk L3, MIN-1 Mb/s, THRESH«0.8 MESS_T 
for each link, a=0.75 and p'=0.5. These traffic weights will 
remain stable until a link stops for synchronization or reports 
a number of packets received less than its THRESH, Con- 
sider the following sequence of events: 

1. Link LI receives a SYNC__ACK containing a 
MESS_R of 24, indicating that only 75% of the 
MESS_T (32) messages transmitted in the last window 
were successfully received. Link 1 would be below 
THRESH (0.8). Consequently, link Li's traffic weight 
value would be reduced to 0.12825, while link L2's 
traffic weight value would be increased to 0,65812 and 
link L3's traffic weight value would be increased to 
0.217938. 

2. Link L2 and L3 remained healthy and link LI stopped 
to synchronize. Then link Li's traffic weight value 
would be set to 0, link L2's traffic weight value would 
be set to 0,75, and Link L33's traffic weight value would 
be set to 0.25. 

3. Link LI finally received a SYNC_ACK containing a 
MESS_R of 0 indicating that none of the MESS_T 
(32) messages transmitted in the last window were 
successfully received. Link LI would be below 
THRESH, Link Ll's traffic weight value would be 
increased to 0.005, link L2's traffic weight value would 
be decreased to 0.74625, and link L3's traffic weight 
value would be decreased to 0,24875. 

4. Link LI received a SYNC__ACK containing a 
MESS_R of 32 indicating that 100% of the MESS_T 
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(32) messages transmitted in the last window were automatically sets up a virtual private network between the 

successfully received. Link LI would be above target node and the user. The VPN is preferably imple- 

THRESH. Link Li's trafiSc weight value would be mented using the IP address "hopping" features of the basic 

increased to 0,2525, while link L2's traffic weight value invention described above, such that the true identity of the 

would be decreased to 0.560625 and link L3's traffic 5 two nodes cannot be determined even if packets during the 

weight value would be decreased to 0.186875. communication are intercepted. For DNS requests that are 

5. Link LI received a SYNC_ACK containing a determined to not require secure services (e.g., an unregis- 
MESS_R of 32 indicating that 100% of the MESS_T t^r^d user), the DNS server transparently "passes through" 
(32) messages transmitted in the last window were ^^e request to provide a normal look-up function and return 
successfully received. Link LI would be above 10 the IP address of the target web server, provided that the 
THRESH. Unk Li's traffic weight value would be ^"^^ permissions to resolve unsecured sites, 
increased to 0.37625; Unk I2's traffic weight value ^^[f "^^^^ an identical DNS request could be 

, , . , ^ . A^^o-i^c 1 Ti7 . az provided With different results, 

would be decreased to 0^678125, and link L3 s traffic ^^^^^ ^ ^ employing various principles 

weight value would be decreased to 0.1559375. summarized above. A user's computer 2601 includes a 

6. Link LI remams healthy and the traffic probabilities 15 conventional client (e.g., a web browser) 2605 and an IP 
approach their steady state traffic probabilities. protocol stack 2606 that preferably operates in accordance 

B. Use of a DNS Proxy to Transparently Create Virtual with an IP hopping function 2607 as outlined above. A 

Private Networks modified DNS server 2602 includes a conventional DNS 

A second improvement concerns the automatic creation of server function 2609 and a DNS proxy 2610. A gatekeeper 

a virtual private network (VPN) in response to a domain- 20 server 2603 is interposed between the modified DNS server 

name server look-up function. and a secure target site 2704. An "imsecure" target site 2611 

Conventional Domain Name Servers (DNSs) provide a is also accessible via conventional IP protocols, 
look-up function that returns the IP address of a requested According to one embodiment, DNS proxy 2610 inter- 
computer or host. For example, when a computer user types cepts all DNS lookup functions from client 2605 and deter- 
in the web name "Yahoo.com," the user's web browser 25 mines whether access to a secm^e site has been requested. If 
transmits a request to a DNS, which converts the name into access to a secure site has been requested (as determined, for 
a four-part IP address that is returned to the user's browser example, by a domain name extension, or by reference to an 
and then used by the browser to contact the destination web internal table of such sites), DNS proxy 2610 determines 
site. whether the user has sufficient security privileges to access 

This conventional scheme is shown in FIG. 25. A user's 30 the site. If so, DNS proxy 2610 transmits a message to 
computer 2501 includes a client application 2504 (for gatekeeper 2603 requesting that a virtual private network be 
example, a web browser) and an IP protocol stack 2505. created between user computer 2601 and secure target site 
When the user enters the name of a destination host, a 2604. In one embodiment, gatekeeper 2603 creates "hop- 
request DNS REQ is made (through IP protocol stack 2505) blocks" to be used by computer 2601 and secure target site 
to a DNS 2502 to look up the IP address associated with the 35 2604 for secure communication. Then, gatekeeper 2603 
name. The DNS returns the IP address DNS RESP to client communicates these to user computer 2601. Thereafter, 
application 2504, which is then able to use the IP address to DNS proxy 2610 returns to user computer 2601 the resolved 
communicate with the host 2503 through separate transac- address passed to it by the gatekeeper (this address could be 
tions such as PAGE REQ and PAGE RESP. different from the actual target computer) 2604, preferably 
' In the conventional architecture shown in FIG. 25, nefari- 40 using a secure administrative VPN. The address that is 
ous listeners on the Internet could intercept the DNS REQ returned need not be the actual address of the destination 
and DNS RESP packets and thus learn what IP addresses the computer. 

user was contacting. For example, if a user wanted to set up Had the user requested lookup of a non-secure web site 

a secure communication path with a web site having the such as site 2611, DNS proxy would merely pass through to 

name "Target.com," when the user's browser contacted a 45 conventional DNS server 2609 the look-up request, which 

DNS to find the IP address for that web site, the true IP would be handled in a conventional manner, returning the IP 

address of that web site would be revealed over the Internet address of non-secure web site 2611. If the user had 

as part of the DNS inquiry. This would hamper anonymous requested lookup of a secure web site but lacked credentials 

communications on the Internet. to create such a connection, DNS proxy 2610 would return 

' One conventional scheme that provides secure virtual 50 a "host unknown" error to the user. In this manner, different 

private networks over the Internet provides the DNS server users requesting access to the same DNS name could be 

with the public keys of the machines that the DNS server has provided with different look-up results, 

the addresses for. This allows hosts to retrieve automatically Gatekeeper 2603 can be implemented on a separate 

the public keys of a host that the host is to communicate with computer (as shown in FIG. 26) or as a function within 

so that the host can set up a VPN without having the user 55 modified DNS server 2602. In general, it is anticipated that 

enter the public key of the destination host. One implemen- gatekeeper 2703 facilitates the allocation and exchange of 

tation of this standard is presently being developed as part of information needed to communicate securely, such as using 

the FreeSAVAN project(RFC 2535). "hopped" IP addresses. Secure hosts such as site 2604 are 

The conventional scheme suffers from certain drawbacks. assumed to be equipped with a secure communication 

For example, any user can perform a DNS request. 60 fimction such as an IP hopping function 2608. 

Moreover, DNS requests resolve to the same value for all It will be appreciated that the functions of DNS proxy 

users. 2610 and DNS server 2609 can be combined into a single 

According to certain aspects of the invention, a special- server for convenience. Moreover, although element 2602 is 

ized DNS server traps DNS requests and, if the request is shown as combining the functions of two servers, the two 

from a special type of user (e.g., one for which secure 65 servers can be made to operate independently, 

communication services are defined), the server does not FIG. 27 shows steps that can be executed by DNS proxy 

return the true IP address of the target node, but instead server 2610 to handle requests for DNS look-up for secure 
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hosts. In step 2701, a DNS look-up request is received for a 
target host. In step 2702, a check is made to determine 
whether access to a secure host was requested. If not, then 
in step 2703 the DNS request is passed to conventional DNS 
server 2609, which looks up the IP address of the target site 5 
and returns it to the user's application for further processing. 

In step 2702, if access to a secure host was requested, then 
in step 2704 a further check is made to determine whether 
the user is authorized to connect to the secure host. Such a 
check can be made with reference to an internally stored list lO 
of authorized IP addresses, or can be made by communi- 
cating with gatekeeper 2603 (e.g., over an "administrative" 
VPN that is secure). It will be appreciated that different 
levels of security can also be provided for different catego- 
ries of hosts. For example, some sites may be designated as 15 
having a certain security level, and the security level of the 
user requesting access must match that security level The 
user's security level can also be determined by transmitting 
a request message back to the user's computer requiring that 
it prove that it has sufficient privileges. 20 

If the user is not authorized to access the secure site, then 
a "host unknown" message is returned (step 2705). If the 
user has sufiGcient security privileges, then in step 2706 a 
secure VPN is established between the user's computer and 
the secure target site. As described above, this is preferably 25 
done by allocating a hopping regime that will be carried out 
between the user's computer and the secure target site, and 
is preferably performed transparently to the user (i.e., the 
user need not be involved in creating the secure link). As 
described in various embodiments of this application, any of 30 
various fields can be "hopped" (e.g., IP source/destination 
addresses; a field in the header; etc.) in order to communi- 
cate secm-ely. 

Some or all of the security functions can be embedded in 
gatekeeper 2603, such that it handles all requests to connect 35 
to secure sites. In this embodiment, DNS proxy 2610 
communicates with gatekeeper 2603 to determine 
(preferably over a secure administrative VPN) whether the 
user has access to a particular web site. Various scenarios for 
implementing these features are described by way of 40 
example below: 

Scenario #1: Client has permission to access target 
computer, and gatekeeper has a rule to make a VPN for the 
client. In this scenario, the client's DNS request would be 
received by the DNS proxy server 2610, which would 45 
forward the request to gatekeeper 2603. The gatekeeper 
would establish a VPN between the client and the requested 
target. The gatekeeper would provide the address of the 
destination to the DNS proxy, which would then return the 
resolved name as a result. The resolved address can be 50 
transmitted back to the client in a secure administrative 
VPN. 

Scenario Client does not have permission to access 
target computer. In this scenario, the client's DNS request 
would be received by the DNS proxy server 2610, which 55 
would forward the request to gatekeeper 2603. The gate- 
keeper woidd reject the request, informing DNS proxy 
server 2610 that it was unable to find the target computer. 
The DNS proxy 2610 would then return a "host unknown" 
error message to the client. 60 

Scenario #3: Client has permission to connect using a 
normal non-VPN link, and the gatekeeper does not have a 
rule to set up a VPN for the cHent to the target site. In this 
scenario, the client's DNS request is received by DNS proxy 
server 2610, which would check its rules and determine that 65 
no VPN is needed. Gatekeeper 2603 would then inform the 
DNS proxy server to forward the request to conventional 



DNS server 2609, which would resolve the request and 
return the result to the DNS proxy server and then back to 
the client. 

Scenario #4: Client does not have permission to establish 
a nonnal/non-VPN link, and the gatekeeper does not have a 
rule to make a VPN for the client to the target site. In this 
scenario, the DNS proxy server would receive the cUent's 
DNS request and forward it to gatekeeper 2603. Gatekeeper 
2603 would determine that no special VPN was needed, but 
that the client is not authorized to communicate with non- 
VPN members. The gatekeeper would reject the request, 
causing DNS proxy server 2610 to return an error message 
to the client. 

C. Large Link to Small Link Bandwidth Management 

One feature of the basic architecture is the ability to 
prevent so-called "denial of service" attacks that can occur 
if a computer hacker floods a known Internet node with 
packets, thus preventing the node from communicating with 
other nodes. Because IP addresses or other fields are 
"hopped" and packets arriving with invalid addresses are 
quickly discarded, Internet nodes are protected against 
flooding targeted at a single IP address. 

In a system in which a computer is coupled through a link 
having a limited bandwidth (e.g., an edge router) to a node 
that can support a much higher-bandwidth link (e.g., an 
Internet Service Provider), a potential weakness could be 
exploited by a determined hacker. Referring to FIG. 28, 
suppose that a first host computer 2801 is communicating 
with a second host computer 2804 using the IP address 
hopping principles described above. The first host computer 
is coupled through an edge router 2802 to an Internet Service 
Provider (ISP) 2803 through a low bandwidth link (LOW 
BW), and is in turn coupled to second host computer 2804 
through parts of the Internet through a high bandwidth fink 
(HIGH BW). In this architecture, the ISP is able to support 
a high bandwidth to the internet, but a much lower band- 
width to the edge router 2802. 

Suppose that a computer hacker is able to transmit a large 
quantity of dummy packets addressed to first host computer 
2801 across high bandwidth link HIGH BW. Normally, host 
computer 2801 would be able to quickly reject the packets 
since they would not fall within the acceptance window 
permitted by the IP address hopping scheme. However, 
because the packets must travel across low bandwidth link 
LOW BW, the packets overwhelm the lower bandwidth link 
before they are received by host computer 2801. 
Consequently, the link to host computer 2801 is effectively 
flooded before the packets can be discarded. 

According to one inventive improvement, a "link guard" 
function 2805 is inserted into the high-bandwidlh node (e.g., 
ISP 2803) that quickly discards packets destined for a 
low-bandwidth target node if they are not valid packets. 
Each packet destined for a low-bandwidth node is crypto- 
graphically authenticated to determine whether it belongs to 
a VPN. If it is not a valid VPN packet, the packet is 
discarded at the high-bandwidth node. If the packet is 
authenticated as belonging to a VPN, the packet is passed 
with high preference. If the packet is a valid non-VPN 
packet, it is passed with a lower quality of service (e.g., 
lower priority). 

In one embodiment, the ISP distinguishes between VPN 
and non-VPN packets using the protocol of the packet. In the 
case of IPSEC [rfc 2401], the packets have IP protocols 420 
and 421. In the case of the TARP VPN, the packets will have 
an IP protocol that is not yet defined. The ISP's link guard, 
2805, maintains a table of vahd VPNs which it uses to 
validate whether VPN packets are cryptographically valid. 
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According to one embodiment,' packets that do not fall 
within any hop windows used by nodes on the low- 
bandwidth link are rejected, or are sent with a lower quality 
of service. One approach for doing this is to provide a copy 
of the IP hopping tables used by the low-bandwidth nodes to 
the high-bandwidth node, such that both the high-bandwidth 
and low-bandwidth nodes track hopped packets (e.g., the 
high-bandwidth node moves its hopping window as valid 
packets are received). In such a scenario, the high- 
bandwidth node discards packets that do not fall within the 
hopping window before they are transmitted over the low- 
bandwidth link. Thus, for example, ISP 2903 maintains a 
copy 2910 of the receive table used by host computer 2901. 
Incoming packets that do not fall within this receive table are 
discarded. According to a different embodiment, link guard 
2805 validates each VPN packet using a keyed hashed 
message authentication code (HMAC) [rfc 2104]. 

According to another embodiment, separate VPNs (using, 
for example, hopblocks) can be established for communi- 
cating between the low-bandwidth node and the high- 
bandwidth node (i.e., packets arriving at the high-bandwidth 
node are converted into different packets before being 
transmitted to the low-bandwidth node). 

As shown in FIG. 29, for example, suppose that a first host 
computer 2900 is communicating with a second host com- 
puter 2902 over the Internet, and the path includes a high 
bandwidth link HIGH BW to an ISP 2901 and a low 
bandwidth link LOW BW through an edge router 2904. In 
accordance with the basic architecture described above, first 
host computer 2900 and second host computer 2902 would 
exchange hopblocks (or a hopblock algorithm) and would be 
able to create matching transmit and receive tables 2905, 
2906, 2912 and 2913. Then in accordance with the basic 
architecture, the two computers would transmit packets 
having seemingly random IP source and destination 
addresses, and each would move a corresponding hopping 
window in its receive table as valid packets were received. 

Suppose that a nefarious computer hacker 2903 was able 
to deduce that packets having a certain range of IP addresses 
(e.g., addresses 100 to 200 for the sake of simplicity) are 
being transmitted to ISP 2901, and that these packets are 
being forwarded over a low-bandwidth link. Hacker com- 
puter 2903 could thus "flood" packets having addresses 
falling into the range 100 to 200, expecting that they would 
be forwarded along low bandwidth link LOW BW, thus 
causing the low bandwidth link to become overwhehued. 
The fast packet reject mechanism in first host computer 3000 
would be of little use in rejecting these packets, since the low 
bandwidth link was effectively jammed before the packets 
could be rejected. In accordance with one aspect of the 
improvement, however, VPN link guard 2911 would prevent 
the attack from impacting the performance of VPN traffic 
because the packets would either be rejected as invalid VPN 
packets or given a lower quality of service than VPN traflSc 
over the lower bandwidth link. A denial-of-service flood 
attack could, however, stfll disrupt non-VPN traffic. 

According to one embodiment of the improvement, ISP 
2901 maintains a separate VPN with first host computer 
2900, and thus translates packets arriving at the ISP into 
packets having a different IP header before they are trans- 
mitted to host computer 2900. The cryptographic keys used 
to authenticate VPN packets at the link guard 2911 and the 
cryptographic keys used to encrypt and decrypt the VPN 
packets at host 2902 and host 2901 can be different, so that 
link guard 2911 does not have access to the private host data; 
it only has the capability to authenticate those packets. 

According to yet a third embodiment, the low-bandwidth 
node can transmit a special message to the high-bandwidth 



node instructing it to shut down all transmissions on a 
particular IP address, such that only hopped packets wfll 
pass through to the low-bandwidth node. This embodiment 
would prevent a hacker from flooding packets using a single 

5 IP address. According to yet a fourth embodiment, the 
high-bandwidth node can be configured to discard packets 
transmitted to the low-bandwidth node if the transmission 
rate exceeds a certain predetermined threshold for any given 
IP address; this would allow hopped packets to go through. 
In this respect, link guard 2911 can be used to detect that the 
rate of packets on a given IP address are exceeding a 
threshold rate; further packets addressed to that same IP 
address would be dropped or transmitted at a lower priority 
(e.g., delayed), 
D. Traffic Umiter 

In a system in which multiple nodes are communicating 
using "hopping" technology, a treasonous insider could 
intemaUy flood the system with packets. In order to prevent 
this possibility, one inventive improvement involves setting 
up "contracts" between nodes in the system, such that a 

20 receiver can impose a bandwidth limitation on each packet 
sender. One technique for doing this is to delay acceptance 
of a checkpoint synchronization request from a sender imtil 
a certain time period (e.g., one minute) has elapsed. Each 
receiver can effectively control the rate at which its hopping 

25 window moves by delaying "SYNC ACK" responses to 
"SYNC_REQ" messages. 

A simple modification to the checkpoint synchronizer wfll 
serve to protect a receiver from accidental or deliberate 
overload from an internally treasonous client. This modifi- 
cation is based on the observation that a receiver wiU not 
update its tables until a SYNC_REQ is received on hopped 
address CKPT__N. It is a simple matter of deferring the 
generation of a new CKPT__N until an appropriate interval 
after previous checkpoints. 
Suppose a receiver wished to restrict reception from a 

35 transmitter to 100 packets a second, and that checkpoint 
synchronization messages were triggered every 50 packets. 
A compliant transmitter would not issue new SYNC_REQ 
messages more often than every 0.5 seconds. The receiver 
could delay a non-compUant transmitter from synchronizing 

40 by delaying the issuance of CKPT_N for 0.5 second after 
the last SYNC_REQ was accepted. 

In general, if M receivers need to restrict N transmitters 
issuing new S YNC_REQ messages after every W messages 
to sending R messages a second in aggregate, each receiver 

45 could defer issuing a new CKPT_N until MxNxW/R sec- 
onds have elapsed since the last SYNC_REQ has been 
received and accepted. If the transmitter exceeds this rate 
between a pair of checkpoints, it wiU issue the new check- 
point before the receiver is ready to receive it, and the 

50 SYNC_REQ will be discarded by the receiver. After this, 
the transmitter will re-issue the SYNC_REQ every Ti 
seconds, until it receives a SYNC_ACK. The receiver wfll 
eventually update CKPT_N and the SYNC_REQ wiU be 
acknowledged. If the transmission rate greatly exceeds the 

55 aUowed rate, the transmitter wfll stop untfl it is compliant. If 
the transmitter exceeds the aUowed rate by a little, it wfll 
eventually stop after several rounds of delayed synchroni- 
zation untfl it is in compliance. Hacking the transmitter's 
code to not shut off only permits the transmitter to lose the 

60 acceptance window. In this case it can recover the window 
and proceed only after it is compliant again. 

Two practical issues shoifld be considered when imple- 
menting the above scheme: 

1. The receiver rate should be slightly higher than the 

65 permitted rate in order to allow for statistical fluctua- 
tions in traffic arrival times and non-uniform load 
balancing. 
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2. Since a transmitter will rightfully continue to transmit SYNC_REQ received from transmitter 3001 was received 

for a period after a SYNC_REQ is transmitted, the at a rate that exceeds the allowable rate R (i.e., the period 

algorithm above can artificially reduce the transmitter's between the time of the last SYNC_REQ message). The 

bandwidth. If events prevent a compliant- transmitter value R can be a constant, or it can be made to fluctuate as 

from synchronizing for a period (e.g. the network 5 desired. If the rate exceeds R, then in step 3008 the next 

droppingaSYNC_REQoraSYNC_^CK)aSYNC_ activation of the next CKPT_N hopping table entry is 

REQ will be accepted later than expected. After this, delayed by W/R seconds after the last SYNC__REQ has 

the transmitter will transmit fewer than expected mes- been accepted. 

sages before encountering the next checkpoint. The Otherwise, if the rate has not been exceeded, then in step 

new checkpoint will not have been activated and the lO 3109 the next CKPT_N value is calculated and inserted into 

transmitter will have to retransmit the SYNC_REQ. the receiver's hopping table prior to the next SYNC_REQ 

This will appear to the receiver as if the transmitter is from the transmitter 3101. Transmitter 3101 then processes 

not compliant. Therefore, the next checkpoint will be the SYNC_REQ in the normal manner, 

accepted late from the transmitter's perspective. This E. Signaling Synchronizer 

has the effect of reducing the transmitter's allowed 15 In a system in which a large number of users communi- 

packet rate until the transmitter transmits at a packet cate with a central node using secure hopping technology, a 

rate below the agreed upon rate for a period of time. large amount of memory must be set aside for hopping tables 

To guard against this, the receiver should keep track of the and their supporting data structures. For example, if one 

times that the last C SYNC__REQs were received and million subscribers to a web site occasionally communicate 

accepted and use the minimum of MxNxW/R seconds after 20 with the web site, the site must maintain one million hopping 

the last SYNC_REQ has been received and accepted, tables, thus using up valuable computer resources, even 

2xMxNxW/R seconds after next to the last SYNC_REQ though only a small percentage of the users may actually be 

has been received and accepted, CxMxNxW/R seconds using the system at any one time. A desirable solution would 

after (C-1)''* to the last SYNC_REQ has been received, as be a system that permits a certain maximum number of 

the time to activate CKPT_N. This prevents the receiver 25 simultaneous links to be maintained, but which would 

from inappropriately limiting the transmitter's packet rate if "recognize" millions of registered users at any one time. In 

at least one out of the last C SYNC_REQs was processed other words, out of a population of a million registered users, 

on the first attempt. a few thousand at a time could simultaneously communicate 

FIG. 30 shows a system employing the above-described with a central server, without requiring that the server 

principles. In FIG. 30, two computers 3000 and 3001 are 30 maintain one milhon hopping tables of appreciable size, 

assumed to be communicating over a network N in accor- One solution is to partition the central node into two 

dance with the "hopping" principles described above (e.g., nodes: a signaling server that performs session initiation for 

hopped IP addresses, discriminator values, etc.). For the sake user log-on and log-oflF (and requires only minimally sized 

of simplicity, computer 3000 will be referred to as the tables), and a transport server that contains larger hopping 

receiving computer and computer 3001 will be referred to as 35 tables for the users. The signaling server listens for the 

the transmitting computer, although full duplex operation is millions of known users and performs a fast -packet reject of 

of course contemplated. Moreover, although only a single other (bogus) packets. When a packet is received from a 

transmitter is shown, multiple transmitters can transmit to known user, the signaling server activates a virtual private 

receiver 3000. link (VPL) between the user and the transport server, where 

As described above, receiving computer 3000 maintains a 40 hopping tables are allocated and maintained. When the user 
receive table 3002 including a window W that defines valid logs onto the signaling server, the user's computer is pro- 
IP address pairs that will be accepted when appearing in vided with hop tables for communicating with the transport 
incoming data packets. Transmitting computer 3001 main- server, thus activating the VPL. The VPLs can be torn down 
tains a transmit table 3003 from which the next IP address when they become inactive for a time period, or they can be 
pairs will be selected when transmitting a packet to receiv- 45 torn down upon user log-out. Communication with the 
ing computer 3000. (For the sake of illustration, window W signaling server to allow user log-on and log-off can be 
is also illustrated with reference to transmit table 3003). As accomplished using a specialized version of the checkpoint 
transmitting computer moves through its table, it will even- scheme described above. 

tually generate a SYNC_REQ message as illustrated in FIG. 31 shows a system employing certain of the above- 
function 3010. This is a request to receiver 3000 to syn- 50 described principles. In FIG. 31, a signaling server 3101 and 
chronize the receive table 3002, from which transmitter a transport server 3102 commtmicate over a link. Signaling 
3001 expects a response in the form of a CKPT_N (included server 3101 contains a large number of small tables 3106 
as part of a SYNC_^CK message). If transmitting com- and 3107 that contain enough information to authenticate a 
puter 3001 transmits more messages than its allotment, it communication request with one or more cUents 3103 and 
will prematurely generate the SYNC_REQ message. (If it 55 3104. As described in more detail below, these small tables 
has been altered to remove the SYNC_REQ message gen- may advantageously be constructed as a special case of the 
eration altogether, it will fall out of synchronization since synchronizing checkpoint tables described previously, 
receiver 3000 will quickly reject packets that fall outside of Transport server 3102, which is preferably a separate com- 
window W, and the extra packets generated by transmitter puter in communication with signaling server 3101, contains 
3001 will be discarded). 60 a smaller number of larger hopping tables 3108, 3109, and 
In accordance with the improvements described above, 3110 that can be allocated to create a VPN with one of the 
receiving computer 3000 performs certain steps when a client computers. 

SYNC_REQ message is received, as illustrated in FIG. 30. According to one embodiment, a client that has previ- 

In step 3004, receiving computer 3000 receives the SYNC_ ously registered with the system (e.g., via a system admin- 

REQ message. In step 3005, a check is made to determine 65 istration function, a user registration procedure, or some 

whether the request is a duplicate. If so, it is discarded in step other method) transmits a request for information from a 

3006. In step 3007, a check is made to determine whether the computer (e.g., a web site). In one variation, the request is 
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made using a "hopped" packet, such that signaling server 
3101 will quickly reject invalid packets from unauthorized 
computers such as hacker computer 3105. An "administra- 
tive" VPN can be established between all of the clients and 
the signaling server in order to ensure that a hacker cannot 5 
flood signaling server 3101 with bogus packets. Details of 
this scheme are provided below. 

Signaling server 3101 receives the request 3111 and uses 
it to determine that client 3103 is a validly registered user. 
Next, signaling server 3101 issues a request to transport jq 
server 3102 to allocate a hopping table (or hopping algo- 
rithm or other regime) for the purpose of creating a VPN 
with client 3103. The allocated hopping parameters are 
returned to signaling server 3101 (path 3113), which then 
supplies the hopping parameters to client 3103 via path 
3114, preferably in encrypted form. 

Thereafter, client 3103 communicates with transport 
server 3102 using the normal hopping techniques described 
above. It will be appreciated that although signaling server 

3101 and transport server 3102 are illustrated as being two 
separate computers, they could of course be combined into ^0 
a single computer and their functions performed on the 
single computer. Alternatively, it is possible to partition the 
functions shown in FIG. 31 differently from as shown 
without departing from the inventive principles. 

One advantage of the above-described architecture is that 25 
signaling server 3101 need only maintain a small amount of 
information on a large number of potential users, yet it 
retains the capability of quickly rejecting packets from 
unauthorized users such as hacker computer 3105. Larger 
data tables needed to perform the hopping and synchroni- 
zation functions are instead maintained in a transport server 
3102, and a smaller number of these tables are needed since 
they are only allocated for "active" links. After a VPN has 
become inactive for a certain time period (e.g., one hour), 
the VPN can be automatically tora down by transport server 

3102 or signaling server 3101. "^^ 
A more detailed description will now be provided regard- 
ing how a special case of the checkpoint synchronization 
feature can be used to implement the signaling scheme 
described above. 

The signaling synchronizer may be required to support 40 
many (millions) of standing, low bandwidth connections. It 
therefore should minimize per-VPL memory usage while 
providing the security offered by hopping technology. In 
order to reduce memory usage in the signaling server, the 
data hopping tables can be completely eliminated and data 45 
can be carried as part of the SYNC_REQ message. The 
table used by the server side (receiver) and client side 
(transmitter) is shown schematically as element 3106 in 
FIG. 31. 

The meaning and behaviors of CKPT_N, CKPT_0 and 
CKPT_R remain the same from the previous description, 
except that CKPT_N can receive a combined data and 
SYNC_REQ message or a SYNC_REQ message without 
the data. 

The protocol is a straightforward extension of the earlier 
synchronizer. Assume that a cHent transmitter is on and the 
tables are synchronized. The initial tables can be generated 
"out of band." For example, a client can log into a web 
server to establish an account over the Internet. The client 
will receive keys etc encrypted over the Internet. 
Meanwhile, the server will set up the signaling VPN on the 60 
signaling server. 

Assuming that a client application wishes to send a packet 
to the server on the client's standing signaling VPL: 
1. The client sends the message marked as a data message 
on the inner header using the transmitter's CKPT__N 65 
address. It turns the transmitter off and starts a timer Tl 
noting CKPT_0. Messages can be one of three types: 
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DATA, SYNC__REQ and SYNC_^CK. In the normal 
algorithm, some potential problems can be prevented 
by identifying each message type as part of the 
encrypted inner header field. In this algorithm, it is 
important to distinguish a data packet and a SYNC_ 
REQ in the signaling synchronizer since the data and 
the SYNC_REQ come in on the same address. 

2. When the server receives a data message on its CKPT_ 
N, it verifies the message and passes it up the stack. The 
message can be verified by checking message type and 
and other information (i.e user credentials) contained in 
the inner header. It replaces its CKPT_0 with 
CKPT_N and generates the next CKPT_N. It updates 
its transmitter side CKPT_R to correspond to the 
client's receiver side CKPT R and transmits a SYNC 
ACK containing CKPT_0 in its payload. 

3. When the client side receiver receives a SYNC_ACK 
on its CKPT_R with a payload matching its transmitter 
side CKPT_0 and the transmitter is off, the transmitter 
is turned on and the receiver side CKPT_R is updated. 
If the SYNC__ACK's payload does not match the 
transmitter side CKPT_0 or the transmitter is on, the 
SYNC _J\CK is simply discarded. 

4. Tl expires: If the transmitter is off and the client's 
transmitter side CKPT_0 matches the CKPT_0 asso- 
ciated with the timer, it starts timer Tl noting CKPT__0 
again, and a SYNC_REQ is sent using the transmit- 
ter's CKPT_0 address. Otherwise, no action is taken. 

5. When the server receives a SYNC_REQ on its 
CKPT_N it replaces its CKPT_0 with CKPT_N and 
generates the next CKPT_N. It updates its transmitter 
side CKPT_R to correspond to the client's receiver 
side CKPT_R and transmits a SYNC_^CK contain- 
ing CKPT__0 in its payload. 

6. When the server receives a SYNC_REO on its 
CKPT_0, it updates its transmitter side CKPT_R to 
correspond to the client's receiver side CKPT_R and 
transmits a SYNC_ACK containing CKPT_0 in its 
payload. 

FIG. 32 shows message flows to highlight the protocol. 
Reading from top to bottom, the client sends data to the 
server using its transmitter side CKPT_N. The client side 
transmitter is turned off and a retry timer is turned off The 
transmitter will not transmit messages as long as the trans- 
mitter is turned off. The client side transmitter then loads 
CKPT_N into CKPT_0 and updates CKPT N. This mes- 
sage is successfuUy received and a passed up the stack. It 
also synchronizes the receiver i.e, the server loads CKPT__N 
into CKPT_0 and generates a new CKPT_N, it generates 
a new CKPT_R in the server side transmitter and transmits 
a SYNC_ACK containing the server side receiver's 
CKPT_0 the server. The SYNC_ACK is successfully 
received at the client. The client side receiver's CKPT_R is 
updated, the transmitter is turned on and the retry timer is 
killed. The client side transmitter is ready to transmit a new 
data message. 

Next, the client sends data to the server using its trans- 
mitter side CKPT_N. The client side transmitter is turned 
off and a retry timer is turned off. The transmitter will not 
transmit messages as long as the transmitter is turned off. 
The client side transmitter then loads CKPT_N into 
CKPT_0 and updates CKPT_N. This message is lost. The 
client side timer expires and as a result a SYNC_REQ is 
transmitted on the client side transmitter's CKPT_0 (this 
will keep happening until the SYNC_ACK has been 
received at the client). The SYNC_REQ is successfully 
received at the server. It synchronizes the receiver i.e, the 
server loads CKPT_N into CKPT_0 and generates a new 
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CKPT_N. it generates an new CKPT_R in the server side 
transmitter and transmits a SYNC_ACK containing the 
server side receiver's CKPT_0 the server. The SYNC__ 
ACK is successfully received at the client. The client side 
receiver's CKPT_R is updated, the transmitter is turned off 5 
and the retry timer is killed. The client side transmitter is 
ready to transmit a new data message. 

There are numerous other scenarios that follow this flow. 
For example, the SYNC_ACK could be lost. The transmit- 
ter would continue to re-send the SYNC_REQ until the 
receiver synchronizes and responds. 

The above-described procedures allow a client to be 
authenticated at signaling server 3201 while maintaining the 
ability of signaling server 3201 to quickly reject invalid 
packets, such as might be generated by hacker computer 
3205. in various embodiments, the signaling synchronizer is 
really a derivative of the synchronizer. It provides the same 
protection as the hopping protocol, and it does so for a large 
number of low bandwidth connections. 

What is claimed is: 

1. A method of transparently creating a virtual private 20 
network (VPN) between a client computer and a target 
computer, comprising the steps of: 

(1) generating from the client computer a Domain Name 
Service (DNS) request that requests an IP address 
corresponding to a domain name associated with the 25 
target computer; 

(2) determining whether the DNS request transmitted in 
step (1) is requesting access to a secure web site; and 

(3) in response to determining that the DNS request in 
step (2) is requesting access to a secure target web site, 
automatically initiating the VPN between the client 
computer and the target computer. 

2. The method of claim 1, wherein steps (2) and (3) are 
performed at a DNS server separate from the client com- 
puter. 

3. The method of claim 1, further comprising the step of: 

(4) in response to determining that the DNS request in 
step (2) is not requesting access to a secure target web 
site, resolving the IP address for the domain name and 
returning the IP address to the client computer. 

4. The method of claim 1, wherein step (3) comprises the 
step of, prior to automatically initiating the VPN between 
the client computer and the target computer, determining 
whether the client computer is authorized to establish a VPN 
with the target computer and, if not so authorized, returning 
an error from the DNS request. 

5. The method of claim 1, wherein step (3) comprises the 
step of, prior to automatically initiating the VPN between 
the client computer and the target computer, determining 
whether the client computer is authorized to resolve 50 
addresses of non secure target computers and, if not so 
authorized, returning an error from the DNS request. 

6. The method of claim 1, wherein step (3) comprises the 
step of establishing the VPN by creating an IP address 
hopping scheme between the client computer and the target 55 
computer. 

7. The method of claim 1, wherein step (3) comprises the 
step of using a gatekeeper computer that allocates VPN 
resources for communicating between the client computer 
and the target computer. 

8. The method of claim 1, wherein step (2) is performed 
in a DNS proxy server that passes through the request to a 
DNS server if it is determined in step (3) that access is not 
being requested to a secure target web site. 

9. The method of claim 5, wherein step (3) comprises the 
step of transmitting a message to the client computer to 
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determine whether the client computer is authorized to 
establish the VPN target computer. 

10. A system that transparently creates a virtual private 
network (VPN) between a client computer and a secure 
target computer, comprising: 

a DNS proxy server that receives a request from the client 
computer to look up an IP address for a domain name, 
wherein the DNS proxy server returns the IP address 
for the requested domain name if it is determined that 
access to a non-secure web site has been requested, and 
wherein the DNS proxy server generates a request to 
create the VPN between the client computer and the 
secure target computer if it is determined that access to 
a secure web site has been requested; and 

a gatekeeper computer that allocates resources for the 
VPN between the client computer and the secure web 
computer in response to the request by the DNS proxy 
server. 

11. The system of claim 10, wherein the gatekeeper 
computer creates the VPN by establishing an IP address 
hopping regime that is used to pseudorandomly change IP 
addresses in packets transmitted between the client com- 
puter and the secure target computer. 

12. The system of claim 10, wherein the gatekeeper 
computer determines whether the client computer has suf- 
ficient security privileges to create the VPN and, if the client 
computer lacks sufficient security privileges, rejecting the 
request to create the VPN. 

13. A method of establishing communication between one 
of a plurality of client computers and a central computer that 
maintains a plurahty of authentication tables each corre- 
sponding to one of the client computers, the method com- 
prising the steps of: 

(1) in the central computer, receiving from one of the 
plurality of client computers a request to establish a 
connection; 

(2) authenticating, with reference to one of the plurality of 
authentication tables, that the request received in step 
(1) is from an authorized client; 

(3) responsive to a determination that the request is from 
an authorized client, allocating resources to establish a 
virtual private link between the client and a second 
computer; and 

(4) communicating between the authorized chent and the 
second computer using the virtual private link. 

14. The method of claim 13, wherein step (4) comprises 
the step of communicating according to a scheme by which 
at least one field in a series of data packets is periodically 
changed according to a known sequence. 

15. The method of claim 14, wherein step (4) comprises 
the step of comparing an Internet Protocol (IP) address in a 
header of each data packet to a table of vahd IP addresses 
maintained in a table in the second computer. 

16. The method of claim 15, wherein step (4) comprises 
the step of comparing the IP address in the header of each 
data packet to a moving window of valid IP addresses, and 
rejecting data packets having IP addresses that do not fall 
within the moving window. 

17. The method of claim 13, wherein step (2) comprises 
the step of using a checkpoint data structure that maintains 
synchronization of a periodically changing parameter 
known by the central computer and the client computer to 
authenticate the client. 

***** 
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